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为 什么 要 写 这 林 刷 


我 从 事 Linux 环 境 的 开发 工作 已 有 近 十 年 的 时 间 ， 但 我 一 直 认 为 工作 时 间 并 不 等 于 经 验 ， 更 不 等 于 
能 力 。 如 何 才能 把 工作 时 间 转 换 为 自己 的 经 验 和 能 力 呢 ? 我 认为 无 非 是 多 阅读 、 多 思考 、 多 实践 、 多 
分 享 。 这 也 是 我 在 ChinaUnix 上 的 博客 座右铭 ， 目 前 我 的 博客 一 共有 247 篇 博文 ， 记 录 的 大 都 是 Linux 内 
核 网 络 部 分 的 源码 分 析 ， 以 及 相关 的 应 用 编程 。 机 械 工 业 出 版 社 华章 公司 的 Lisa 正 是 通过 我 的 博客 找到 
我 的 ， 而 这 也 促成 了 本 书 的 出 版 。 






































其 实在 Lisa 之 前 ， 就 有 另外 一 位 编辑 与 我 聊 过 ， 但 当时 我 没有 下 好 决心 ， 认 为 自己 无 论 是 在 技术 水 
平 ， 还 是 时 间 安 排 上 ， 都 不 足以 完成 一 本 技术 图 书 的 创作 。 等 到 与 Lisa 洽 谈 的 时 候 ， 我 感觉 自己 的 技术 
己 经 有 了 一 些 沉淀 ， 同 时 时 间 也 相对 比较 充裕 ， 因 此 决定 开始 撰写 自己 技术 生涯 的 第 一 本 书 。 























对 于 Linux 环 境 的 开发 人 员 ，《Unix 环 境 高 级 编程 》〔 后 文 均 简 称 为 APUE) 无疑 是 最 为 经 典 的 入 门 
书籍 。 其 作者 Stevens 是 我 从 业 以 来 最 崇拜 的 技术 专家 。 他 的 Advanced Programming in the Unix 
Environment、Unix Network Programming 系 列 及 TCP/IP Illustrated 系 列 著 作 ， 字 字 珠 丽 ， 本 本 经 典 。 在 我 
从 业 的 最 初 几 年 ， 这 几 本 书 每 本 都 阅读 了 好 几 遍 ， 而 这 也 为 我 进行 Linux 用 户 空间 的 开发 莫 定 了 坚实 的 
基础 。 在 掌握 了 这 些 知 识 以 后 ， 如 何 继续 提高 自己 的 技能 呢 ? 经 过 一 番 思 考 ， 我 选择 了 阅读 Linux 内 核 
源码 ， 并 尝试 将 内 核 与 应 用 融会 贯通 。 在 阅读 了 一 定量 的 内 核 源码 之 后 ， 我 才 真 正 理解 了 Linux 专 家 的 
这 人 句 话 “Read the fucking codes”"。 只 有 阅读 了 内 核 源码 ， 才 能 真正 理解 Linux 内 核 的 原理 和 运行 机 制 ， 而 
此 时 ， 我 也 发 现 了 Stevens 著 作 的 一 个 局 限 一 -APUE 和 UNP 毕 葛 是 针对 Unix 环 境 而 写 的 ，Linux 虽 然 大 部 
分 与 Unix 兼 容 ， 但 是 在 很 多 行为 上 与 Unix 还 是 完全 不 同 的 。 这 就 导致 了 书 中 的 一 些 内 容 与 Linux 环 境 中 
的 实际 效果 是 相互 矛盾 的 。 























现在 有 机 会 来 写 一 本 技术 图 书 ， 我 就 想 在 向 Stevens 致 敬 的 同时 ， 写 一 本 类 似 于 APUE 风 格 的 技术 图 
书 ， 同 时 还 要 在 Linux 环 境 下 ， 对 APUE 进 行 突破 。 大 言 不 怖 地 说 ， 我 期 待 这 本 书 可 以 作为 APUE 的 补 
充 ， 还 可 以 作为 Linux 开 发 人 员 的 进 阶 读物 。 事 实 上 ， 本 书 的 写作 布局 正 是 以 APUE 的 章节 作为 参考 ， 针 
对 Linux 环 境 ， 不 仅 对 用 户 空间 的 接口 进行 阐述 ， 同 时 还 引导 读者 分 析 该 接口 在 内 核 的 源码 实现 ， 使 得 
读者 不 仅 可 以 知道 接口 怎么 用 ， 同 时 还 可 以 理解 接口 是 怎么 工作 的 。 对 于 Linux 的 系统 调用 ， 做 到 知 其 
然 ， 知 其 所 以 然 。 

















读者 对 象 


根据 本 书 的 内 容 ， 我 觉得 适合 以 下 几 类 读者 : 








在 Linux 应 用 层 方面 有 一 定 开发 经 验 的 程序 员 。 








对 Linux 内 核 有 兴趣 的 程序 员 。 


-热爱 Linux 内 核 和 开源 项 目的 技术 人 员 。 


如 何 阅读 本 书 


本 书 定位 为 APUE 的 补充 或 进 阶 读物 ， 所 以 假设 读者 已 具备 了 一 定 的 编程 基础 ， 对 Linux 环 境 也 有 所 
了 解 ， 因 此 在 涉及 一 些 基 本 概念 和 知识 时 ， 只 是 晴 猎 点 水 ， 简 单 略 过 。 因 为 笔者 希望 把 更 多 的 笔墨 放 
在 更 为 重要 的 部 分 ， 而 不 是 各 种 相关 图 书 均 有 讲解 的 基本 概念 上 。 所 以 如 果 你 是 初学 者 ， 建 议 还 是 先 
学 习 APUE、C 语 言 编程 ， 并 且 在 上 共有 一 定 的 操作 系统 知识 后 再 来 阅读 本 书 。 





























Linux 环 境 编 程 涉及 的 领域 太 多 ， 很 难 有 某 个 人 可 以 在 Linux 的 各 个 领域 均 有 比较 深刻 的 认识 ， 尤 其 
是 已 有 APUE 这 本 经 典 图 书 在 前 ， 所 以 本 书 是 由 高 峰 、 李 彬 两 个 人 共同 完成 的 。 














高 峰 负责 第 、1、2、3、4、12、13、14、15 章 ， 李 梢 负责 第 5~11 章 。 两 位 不 同 的 作者 ， 在 写作 风 
格 上 很 难保 证 一 致 ， 如 果 给 各 位 读者 带 来 了 不 便 ， 在 此 给 各 位 先 道 个 歉 。 尽 管 是 由 两 个 人 共同 写作 ， 
并 且 负 责 的 还 是 我 们 各 自 相 对 擅长 的 领域 ， 可 是 在 写作 的 过 程 中 我 们 仍然 感觉 到 很 吃力 ， 用 了 将 近 三 
年 的 时 间 才 算 完 成 本 书 。 对 比 APUE， 本 书 一 方面 在 深度 上 还 是 有 所 不 及 ， 男 一 方面 在 广度 上 还 是 没有 
涵盖 APUE 涉 及 的 所 有 领域 ， 这 也 让 我 们 对 Stevens 大 师 更 加 敬佩 。 























本 书 使 用 的 Linux 内 核 源 代码 版 本 为 3.2.44，glibe 的 源码 版 本 为 2.17。 
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第 0 章 ”基础 知识 








基础 知识 是 构建 技术 大 厦 不 可 或 缺 的 稳定 基石 ， 因 此 ， 本 书 首 先 来 介绍 一 下 书 中 所 涉及 的 一 些 基 
础 知识 。 这 里 以 第 0 章 命名 ， 表 明 我 们 要 注重 基础 ， 从 0 开始 ， 同 时 也 是 向 伟大 的 C 语 言 致敬 。 








基础 知识 看 似 简 单 ， 但 是 想 要 真正 理解 它们 ， 是 需要 人 花 一 番 功 夫 的 。 除 了 需要 积累 经 验 以 外 ， 更 
需要 对 它们 进行 不 断 的 思考 和 理解 ， 这 样 ， 才 能 写 出 高 可 靠 性 的 程序 。 这 些 基 础 知识 很 多 都 可 以 独立 
成 文 ， 限 于 篇 幅 ， 这 里 只 能 是 简单 的 介绍 ， 都 是 笔者 根据 自己 的 经 验 和 理解 进行 的 总 结 和 概括 ， 相 信 
对 读者 会 有 所 帮助 。 感 兴趣 的 朋友 可 以 自己 查找 更 多 的 资料 ， 以 得 到 更 准确 、 更 细致 的 介绍 。 


























© 注意 “本 书 中 的 示例 代码 为 了 简洁 明了 ， 没 有 考虑 代码 的 健壮 性 ， 例 如 不 检查 函数 的 返回 
值 、 使 用 全 局 变量 等 。 


0.1 一 个 Linux 程 序 的 诞生 记 


一 本 编程 书籍 如 果 开 篇 不 写 一 个 “hello world”， 就 违背 了 “自古 以 来 ”的 传统 了 。 因 此 本 节 也 将 以 
hello world 为 例 来 说 明 一 个 Linux 程 序 的 诞生 过 程 ， 示 例 代码 如 下 : 





#include <stdio.h> 
int main (void) 


printf ("Hello world!\n"); 
return 0; 
} 


下 面 使 用 gcc 生 成 可 执行 程序 ，gcc-g-Wall 0 1 hello world.c-o hello world。 这 样 ， 一 个 Linux 可 执 
行程 序 就 诞生 了 。 








整个 过 程 看 似 简单 ， 其 实 涉及 预 处理 、 编 译 、 汇 编 和 链接 等 多 个 步骤 。 只 不 过 gcc 作 为 一 个 工具 集 
自动 完成 了 所 有 的 步 又。 下面 就 分 别 来 看 看 其 中 所 涉及 的 各 个 步骤 。 























首先 来 了 解 一 下 什么 是 预 处 理 。 预 处 理 用 于 处 理 预 处 理 命令 。 对 于 上 面 的 代码 来 说 ， 唯 一 的 预 处 
理 命令 就 是 #include。 它 的 作用 是 将 头 文件 的 内 容 包 含 到 本 文件 中 。 注 意 ， 这 里 的 “包含 ” 指 的 是 该 头 文 
件 中 的 所 有 代码 都 会 在 ##nclude 处 展开 。 可 以 通过 “gcc-E 0 1 hello world.c" 在 预 处 理 后 自动 停止 后 面 的 
操作 ， 并 把 预 处 理 的 结果 输出 到 标准 输出 。 因 此 使 用 “gcc-E0_1_hello world.c>0_1_hello world.i”， 可 
得 到 预 处 理 后 的 文件 。 

























































































理解 了 预 处 理 ， 在 出 现 一 些 常见 的 错误 时 ， 才 能 明白 其 中 的 原因 。 比 如 ， 为 什么 不 能 在 头 文件 中 
定义 全 局 变量 ? 这 是 因为 定义 全 局 变量 的 代码 会 存在 于 所 有 以 扑 nclude 包 含 该 头 文件 的 文件 中 ， 也 就 是 
说 所 有 的 这 些 文件 ， 都 会 定义 一 个 同样 的 全 局 变量 ， 这 样 就 不 可 避免 地 造成 了 冲突 。 









































编译 环节 是 指 对 源 代 码 进行 语法 分 析 ， 并 优化 产生 对 应 的 汇编 代码 的 过 程 。 同 样 ， 可 以 使 用 gcc 得 
到 汇编 代码 ， 而 非 最 终 的 二 进 制 文件 ， 即 “gcc-S 0_1 hello world.c-o 0 1 hello world.s”"。gcc 的 -S 选 项 
会 让 gcc 在 编译 完成 后 停止 后 面 的 工作 ， 这 样 只 会 产生 对 应 的 汇编 文件 。 


























汇编 的 过 程 比 较 简单 ， 就 是 将 源 代 码 翻 译 成 可 执行 的 指令 ， 并 生成 目标 文件 。 对 应 的 gcc 命 令 
为 “gcc-c 0 1 _ hello world.c-o 0 1 hello world.o”。 











链接 是 生成 最 终 可 执行 程序 的 最 后 一 个 步骤 ， 也 是 比较 复杂 的 一 步 。 它 的 工作 就 是 将 各 个 目标 文 
件 一 一 包括 库 文件 〈 库 文件 也 是 一 种 目标 文件 ) 链接 成 一 个 可 执行 程序 。 在 这 个 过 程 中 ， 涉 及 的 概念 
比较 多 ， 如 地 址 和 空间 的 分 配 、 符 号 解析 、 重 定位 等 。 在 Linux 环 节 下 ， 该 工作 是 由 GNU 的 链接 器 1d 完 
成 的 。 

















实际 上 我 们 可 以 使 用 -v 选 项 来 查看 完整 和 详细 的 gcc 编 译 过 程 


名 
心 
营 
wa 








gcc -9 -Wall -7 0 1 hello word.c -oO hello world., 





由 于 输出 过 多 ， 此 处 就 不 粘贴 结果 了 。 感 兴趣 的 朋友 可 以 自行 执行 命令 ， 碍 看 输出 。 通 过 -v 选 
项 ， 可 以 看 到 gcc 在 背后 做 了 哪些 具体 的 工作 。 





0.2 程序 的 构成 





Linux 下 二 进 制 可 执行 程序 的 格式 一 般 为 ELF 格 式 。 


ELF 格 式 ， 内 容 如 下 : 





表 组 成 的 。 在 上 面 的 section 列 表 中 ， 大 家 最 


占用 物理 空间 


ELF Header: 

Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 
Class: ELF32 

Data: 2's complement, little endian 

Version: 1 (current) 


OS/ABI: UNIX - System V 

ABI Version: 0 

Type: EXEC (Executable file) 
Machine: Intel 80386 
Version: Oxl 

Entry point address: 
Start of program headers: 
Start of section headers: 
Flags: Ox0 

Size of this header: 52 (bytes) 
Size of program headers: 32 (pytes) 
Number of program headers: 9 

Size of section headers: 40 (pytes) 
Number of section headers: 36 


0x8048320 
52 (bytes into file) 
5148 (bytes into file) 


































































































以 0.1 节 的 hello world 为 例 ， 使 用 readelf 查 看 其 


Section header string table index: 33 
Section Headers: 

Nr] Name Type Addr Off Size ES Flg Lk Inf Al 

0] NULL 00000000 000000 000000 00 0 0 0 

1] .interp PROGBITS 08048154 000154 000013 00 A001 

2] .note.ABI-tag NOTE 08048168 000168 000020 00 A 004 

3] .note.gnu.build-i NOTE 08048188 000188 000024 00 A004 

4] .gnu.hash GNU HASH 080481lac 000lac 000020 04 A504 

5] .dynsym DYNSYM 080481lcc 0001lcc 000050 10A614 

6] .dynstr STRTAB 0804821c 00021c 00004a 00 A001 

7] .gnu.version VERSYM 08048266 000266 00000a 02 A502 

8] .gnu.version r VERNEED 08048270 000270 000020 00 A614 

9] .rel.dyn REL 08048290 000290 000008 08 A 504 

10] .rel.plt REL 08048298 000298 000018 08 A 5 12 4 

11] .init PROGBITS 080482b0 0002b0 000024 00 AX 0 0 4 

12] .plt PROGBITS 080482e0 0002e0 000040 04 AX 0 0 16 

13] .text PROGBITS 08048320 000320 000188 00 AX 0 0 16 

14] .fini PROGBITS 080484a8 0004a8 000015 00 AX 0 0 4 

15] .rodata PROGBITS 080484c0 0004c0 000015 00 A 004 

16] .eh frame hdr PROGBITS 080484d8 0004d8 000034 00 A 004 
17] .eh frame PROGBITS 0804850c 00050c 0000c4 00 A004 

18] .init array INIT ARRAY 08049f08 000f08 000004 00 WA 0 0 4 
19] .fini array FINI ARRAY 08049f0c 000f0c 000004 00 WA 0 0 4 
20] .jcr PROGBITS 08049f10 000f10 000004 00 WA 0 0 4 

21] .dynamic DYNAMIC 08049f14 000f14 0000e8 08 WA 6 04 

22] .got PROGBITS 08049ffc 000ffc 000004 04 WA 0 0 4 

23] .got.plt PROGBITS 0804a000 001000 000018 04 WA 0 0 4 

24] .data PROGBITS 0804a018 001018 000008 00 WA 0 04 

25] .bss NOBITS 0804a020 001020 000004 00 WA 0 0 4 

26] .comment PROGBITS 00000000 001020 00006b 01 MS 0 01 

27] .debug aranges PROGBITS 00000000 00108b 000020 00 0 01 
28] .debug info PROGBITS 00000000 0010ab 000094 00 0 01 

29] .debug abbrev PROGBITS 00000000 00113f£ 000044 00 0 0 1 
30] .debug line PROGBITS 00000000 001183 000043 00 0 01 

31] .debug str PROGBITS 00000000 0011c6 0000cb 01 MS 0 0 1 
32] .debug loc PROGBITS 00000000 001291 000038 00 001 

33] .shstrtab STRTAB 00000000 0012c9 000151 00 0 01 

34] .symtab SYMTAB 00000000 0019bc 000490 10 35 51 4 

35] .strtab STRTAB 00000000 001le4c 00025a 00 0 01 
































由 于 输出 过 多 ， 后 面 的 结果 并 没有 完全 展示 出 来 。ELF 文 件 的 主要 内 容 就 是 由 各 个 section 及 symbol 








就 洒 
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的 应 该 是 text 段 、data 段 和 bss 段 。text 段 为 代码 段 ， 用 于 
保存 可 执行 指令 。data 段 为 数据 段 ， 用 于 保存 有 非 0 初始 值 的 全 局 变量 和 静态 变量 。bss 段 用 于 保存 没有 
初始 值 或 初 值 为 0 的 全 局 变量 和 静态 变量 ， 当 程序 加 载 时 ，bss 段 中 的 变量 会 被 初始 化 为 0。 这 个 段 并 不 
因为 完全 没有 必要 ， 这 些 变量 的 值 固 定 初 始 化 为 0， 因 此 何必 占用 宝贵 的 物理 空间 ? 














其 他 段 没 有 这 三 个 段 有 名 ， 下 面 来 介绍 一 下 其 中 一 些 比较 常见 的 段 : 


“debug 段 : 顾名思义 ， 用 于 保存 调试 信息 。 





dynamic 段 : 用 于 保存 动态 链接 信息 。 


-fini 段 : 用 于 保存 进程 退出 时 的 执行 程序 。 当 进程 结束 时 ， 系 统 会 自动 执行 这 部 分 代码 。 














init 段 : 用 于 保存 进程 启动 时 的 执行 程序 。 当 进程 启动 时 ， 系 统 会 自动 执行 这 部 分 代码 。 








:Todata 段 : 用 于 保存 只 读数 据 ， 如 const 修 饰 的 全 局 变量 、 字 符 串 常量 。 
"symtab 段 : 用 于 保存 符号 表 。 


其 中 ， 对 于 与 调试 相关 的 段 ， 如 果 不 使 用 -g 选 项 ， 则 不 会 生成 ， 但 是 与 符号 相关 的 段 仍 然 会 存在 ， 
这 时 可 以 使 用 strip 去 掉 符 号 信息 ， 感 兴趣 的 朋友 可 以 自己 参考 strip 的 说 明 进行 实验 。 一 般 在 拘 入 式 的 产 
品 中 ， 为 了 减少 程序 占用 的 空间 ， 都 会 使 用 strip 去 掉 非 必要 的 段 。 














0.3 程序 是 如 何 “ 跑 ”的 


















































在 日 常 工作 中 ， 我 们 经 常会 说 “程序 “ 跑 ” 起 来 了 ”"， 那 么 它 到 底 是 怎么 “ 跑 ” 的 呢 ?” 在 Linux 环 境 下 ， 可 以 使 用 strace 跟 踪 系 统 调 | 
加 载 、 运 行 和 退出 的 过 程 。 此 处 仍然 以 hello_world 为 例 。 

















]， 从 而 帮助 自己 研究 系统 程 请 























三 





strace ./hello world 


execve("./hello world", ["./hello world"], [/* 59 vars */]) = 0 

brk(0) = 0x872a000 加 

access("/etc/ld.so.nohwcap", F OK) = -1 ENOENT (No such file or directory) 

mmap2 (NULL, 8192, PROT READ|PROT WRITE, MAP PRIVATE|MAP ANONYMOUS, -1, 0) = 0xb7778000 
access("/etc/1ld.so.preload", R OK) = -1 ENOENT (No such file or directory) 
open{("/etc/ld.so.cache", 0 ) RDONLY|O CLOEXEC) = 3 

fstat64(3, {st mode=S IFREG|0644, st size=80063, ...}) = 0 

mmap2 (NULL, 80063, PROT READ, MAP PRIVATE, 3, 0) = 0xb7764000 

close(3) = 0 

access("/etc/ld.so.nohwcap", F OK) = -1 ENOENT (No such file or directory) 
open("/1ib/i386-linux-gnu/libc.so.6", O RDONLY|O CLOEXEC) = 3 

read (3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\O\3\0\3\0VI\0\0\0000\226\1\0004\0\0\0"..., 512) = 512 
fstat64(3, {st mode=S IFREG|0755, st size=1730024, ...}) = 0 


mmap2 (NULL, 1743580, BROT READ|PROT EXEC, MAP PRIVATE|MAP DENYWRITE, 3, 0)= 0xb75ba000 

mprotect (0xb7759000, 4096, PROT NONE) = 0 

mmap2 (0xb775e000, 12288, PROT READ|PROT WRITE, MAP PRIVATE|MAP FIXEDIMAP DENYWRITE, 3, 0xla3) = 0xb775e000 
mmap2 (0xb7761000, 10972, PROT READ|PROT WRITE, MAP PRIVATE |MAP FIXED|MAP ANONYMOUS, -1, 0) = 0xb7761000 


close(3) = 0 
mmap2 (NULL, 4096, PROT READ|PROT WRITE, MAP PRIVATE|MAP ANONYMOUS, -1, 0) = 0xb75b9000 
set thread | area ({entry 1 number:-1 -> 6, base . addr:0xb75b3900, limit:1048575, seg_ 32bit:1, contents:0, read exec only:0, limit in pages:1l, seg not present:0, useable:1}) = 0 


mprotect (0xb775e000, 8192, PROT READ) = 0 
mprotect (0x8049000, 4096, PROT_ READ) = 0 
mprotect (0xb779b000, 4096, PROT READ) = 0 
munmap (0xb7764000, 80063) = 0 
fstat64(1, {st mode=S IFCHR|0620, st rdev=makedev(136, 3), ...}) = 0 

mmap2 (NULL, 4096, PROT READ|PROT WRITE, MAP ”PRIVATE |MAP_ ANONYMOUS, -1, 0) = 0xb7777000 
write(1，"Hello world!\n", 13Hello world! 

) = 13 

exit group(0) = ? 





























下 




















下 面 就 针对 strace 输 出 说 明 其 含义 。 在 Linux 环 境 中 ， 执 行 一 个 命令 时 ， 首 先是 由 shell 调 用 fork， 然 后 在 子 进程 中 来 真正 执行 这 个 命令 (这 一 过 程 在 strace 输 
无 法 体现 ) 。strace 是 hello_world 开 始 执 行 后 的 输出 。 首 先是 调用 execve 来 加 载 hello_world， 然 后 1d 会 分 别 检查 1d.so.nohwcap 和 1d.so.preload。 其 中 ， 如 果 
1d.so.nohwcap 存 在 ， 则 ld 会 加 载 其 中 未 优化 版 本 的 库 。 如 果 1d.so.preload 存 在 ， 则 ld 会 加 载 其 中 的 库 一 一 在 一 些 项 我 们 需要 拦截 或 蔡 换 系统 调用 或 C 库 ， 此 
时 就 会 利用 这 个 机 制 ， 使 用 LD_PRELOAD 来 实现 。 之 后 利用 mmap 将 1d.so.cache 映 射 到 内 存 中 ，1d.so.cache 中 保存 了 库 的 路 径 ， 这 样 就 完成 了 所 有 的 准备 工作 。 接 
着 1d 加 载 c 库 一 -libc.so.6， 利 用 mmap 及 mprotect 设 置 程序 的 各 个 内 存 区 域 ， 到 这 里 ， 程 序 运行 的 环境 已 经 完成 。 后 面 的 write 会 向 文件 描述 符 1 〈 即 标准 输出 ) 输 
bh"Hello world! mm"， 返 回 值 为 13， 它 表示 write 成 功 的 字符 个 数 。 最 后 调用 exit_group 退 出 程序 ， 此 时 参数 为 0， 表 示 程 序 退 出 的 状态 
返回 0。 
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此 例 中 hello-world 程 序 




















0.4.1 系统 调用 











系统 调用 是 操作 系统 提供 的 服务 ， 是 应 用 程序 与 内 核 通 信 的 接口 。 在 x86 平 台 上 ， 有 多 种 陷入 内 核 
的 途径 ， 最 早 是 通过 int 0x80 指 令 来 实现 的 ， 后 来 ntel 增 加 了 一 个 新 的 指令 sysenter 来 代 蔡 int 0x80 
他 CPU 三 商 也 增加 了 类 似 的 指令 。 新 指令 sysenter 的 性 能 消耗 大 约 是 int 0x80 的 一 半 左 右 。 即 使 是 这 样 ， 
相对 于 普通 的 函数 调用 来 说 ， 系 统 调 用 的 性 能 消耗 也 是 巨大 的 。 所 以 在 追求 极致 性 能 的 程序 中 ， 都 在 
尽力 避免 系统 调用 ， 辟 如 C 库 的 gettimeofday 就 避免 了 系统 调用 。 




















户 空间 的 程序 默认 是 通过 栈 来 传递 参数 的 。 对 于 系统 调用 来 次， 内核 态 和 用 户 态 使 用 的 是 不 同 
的 栈 ， 这 使 得 系统 调用 的 参数 只 能 通过 寄存 器 的 方式 进行 传递 。 





有 心 的 朋友 可 能 会 想到 一 个 问题 : 在 写 代码 的 时 候 ， 程 序 员 根本 不 用 关心 参数 是 如 何 传递 的 ， 纺 
译 器 已 经 默默 地 为 我 们 做 了 一 切 一 一 压 栈 、 出 栈 、 保 存 返 回 地 址 等 操作 ， 但 是 编译 器 如 何 知道 调用 的 
函数 是 普通 函数 ， 还 是 系统 调用 呢 ? 如 果 是 后 者 ， 编 译 器 就 不 能 简单 地 使 用 栈 来 传递 参数 了 。 

















为 了 解决 这 个 问题 ， 我 们 就 要 看 0.4.2 节 介绍 的 C 库 函数 了 。 


0.4.2 C 库 函数 





0.4.1 节 提 到 C 库 函数 为 编译 器 解决 了 系统 调用 的 问题 。Linux 环 境 下 ， 使 用 的 C 库 一 般 都 是 glibc， 它 
封装 了 几乎 所 有 的 系统 调用 ， 代 码 中 使 用 的 “系统 调用 ”， 实 际 上 就 是 调用 C 库 中 的 函数 。C 库 函数 同样 
位 于 用 户 态 ， 所 以 编译 器 可 以 统一 处 理 所 有 的 函数 调用 ， 而 不 用 区 分 该 函数 到 底 是 不 是 系统 调用 。 


























下 面 以 具体 的 系统 调用 open 来 看 看 glibc 库 是 如 何 封装 系统 调用 的 。 在 glibc 的 代码 中 ， 用 了 大 量 的 
编译 器 特性 以 及 编程 的 技巧 ， 可 读 性 不 高 。open 在 glibc 中 对 应 的 实现 函数 实际 上 是 _open_nocancel。 至 
于 如 何 定位 到 它 ， 感 兴趣 的 朋友 可 以 用 _open_nocancel 或 open 作 为 关键 字 ， 在 glibc 的 源码 中 搜索 ， 找 出 
它们 之 间 的 关系 。 








int 
__open nocancel (const char *file, int oflag, ...) 


int mode = 0; 

if (oflag & O CREAT) 

{ 
va list arg; 
va start (arg, oflag); 
mode = va arg (arg, int); 
va end (arg); 


} 
return INLINE SYSCALL (openat, 4, AT FDCWD, file, oflag, mode); 


其 中 INLINE_SYSCAIL 是 我 们 关心 的 内 容 ， 这 个 宏 完 成 了 对 真正 系统 调用 的 封装 : 
INLINE_SYSCALL->INTERNAL SYSCALL。 实 现 INTERNAL SYSCAIL 的 一 个 实例 为 。 


# define INTERNAL SYSCALL (name, err, nr, args...) 


register unsigned int resultvar; 
EXTRAVAR ##nr 
asm volatile ( 
LOADARGS ##nr 
"mov1 %1, %S%eax\n\t" 
"int $0x80\n\t" 
RESTOREARGS ##nr 
: "=a" (resultvar) 





a a a 


"i" (_ NR ##name) ASMFMT ##nr (args) : "memory", "cc"); 
(int) resultvar; }) 





其 中 ， 关 键 的 代码 是 用 和 藤 入 式 汇 编写 的 ， 在 此 只 做 简单 说 明 。 “move%1，%%eax" 表 示 将 第 一 个 参 
数 ( 即 _NR 坟 name) 赋 给 寄存 器 eax。 NR 撩 name 为 对 应 的 系统 调用 号 ， 对 于 本 例 中 的 open 来 说 ， 
其 为 ”NR openat。 系 统 调用 号 在 文件 /usr/include/asmyunitstd 32 (64) .h 中 定义 ， 代 码 如 下 : 








[fgao@fgao understanding apue]#cat /usr/include/asm/unistd 32.h | grep openat 
#define _NR openat 295 





也 就 是 说 ， 在 Linux 平 台 下 ， 系 统 调用 的 约定 是 使 用 寄存 器 eax 来 传递 系统 调用 号 的 。 至 于 参数 的 传 
递 ， 在 glibc 中 也 有 详细 的 说 明 ， 参 见 文件 sysdeps/unix/syswlinuxwi386/sysdep.h。 








043 化 程 安全 


线程 安全 ， 顾 名 思 义 是 指 代码 可 以 在 多 线程 环境 下 “安全 ”地 执行 。 何 谓 安全 ? 即 符合 正确 的 逻辑 
结果 ， 是 程序 员 期 望 的 正常 执行 结果 。 为 了 实现 线程 安全 ， 该 代码 要 么 只 能 使 用 局 部 变量 或 资源 ， 要 
么 就 是 利用 锁 等 同步 机 制 ， 来 实现 全 局 变量 或 资源 的 串 行 访问 。 




















下 面 是 一 个 经 典 的 多 线程 不 安全 代码 : 





#include <pthread.h> 

#include <stdio.h> 

#include <stdlib.h> 

static int counter = 0; 

#define LOOPS 10000000 
static void * thread(void * unused) 


{ 


了 而 疙 -开交 
for (i = 0; i < LOOPS; ++i) { 
++eounters 


. 
return NULL; 
int main (voidqd) 


pthread t t1, t2; 

pthread create(&t1l, NULL, thread, NULL); 
pthread create(&t2, NULL, thread, NULL); 
pthread join(t1l, NULL); 

pthread join(t2, NULL); 

printf ("Counter is %d by threads\n", counter); 
return 0; 





© 注意 “之 所 以 这 里 的 LOOPS 选 用 了 一 个 比较 大 的 数 “10000000”， 是 为 了 保证 第 一 个 线程 不 
要 在 第 二 个 线程 开始 执行 前 就 退出 了 。 大 家 可 以 根据 自己 的 运行 环境 来 修改 这 个 数值 。 




















以 上 代码 创建 了 两 个 线程 ， 用 来 实现 对 同一 个 全 局 变量 进行 自 加 运算 ， 循 环 次 数 为 一 干 万 次 。 下 
面 来 看 一 下 运行 结果 : 


注 











[fgao@fgao chapter0]#./threads counter 
Counter is 10843915 by threads 














为 什么 最 后 的 结果 不 是 期 望 的 20000000 呢 ?下 面 反 汇编 将 来 揭 开 这 个 秘密 一 一 反 汇 编 是 理解 程序 
行为 的 不 二 利器 ， 因 为 它 更 贴近 机 器 语言 ， 也 就 是 说 ， 反 汇编 更 贴近 CPU 运行 的 真相 。 





下 面 对 线 程 函 数 thread 进 行 反 汇编 ， 代 码 如 下 : 





080484a4 <thread>: 
80484a4: 与 与 Push Sebp 


80484a5: 89 e5 IOV Sesp, gsebp 

80484a7: 83 ec 10 sub $0x10, Sesp 

80484aa: c7 45 fc 00 00 00 00 movl $0x0, -0x4 (Sebp) 

80484b1: eb 11 jmp 80484c4 <thread+0x20>80484b3: 


al 94 98 04 08 


Ox8049894, %eax 


80484b8 : 


8 已 0 0 


adqd 


$0xl1, Seax 


80484bb: 


a3 94 98 04 08 


Seax, Ox8049894 


80484c0: 83 45 fc 01 adqdl $0x1,—-0x4 (%ebp) 
80484c4: 81 7d fc 7f 96 98 00 cmpl $0x98967f,-0x4 (Sebp) 
80484cb: 7e e6 jle 80484b3 <thread+0xf> 
80484cd: b8 00 00 00 00 mov $0x0, Seax 

80484d2: C9 leave 

80484d3: G3 ret 


其 中 加 粗 部 分 对 应 的 是 ++counter 的 汇编 代码 ， 其 逻辑 如 下 : 
1) 将 counter 的 值 赋 给 寄存 器 EAX; 

2) 对 寄存 器 EAX 的 值 加 1; 

3) 将 EAX 的 值 赋 给 counter。 


假设 目前 counter 的 值 为 0， 那 么 当 两 个 线程 同时 执行 ++counter 时 ， 会 有 如 下 情况 〈 每 个 线程 会 有 独 
立 的 上 下 文 执行 环境 ， 所 以 可 视 为 每 个 线程 都 有 一 个 “独立 ”的 EAX) : 

















threadl thread2 
eax = Counter => eax = 0 





eax = counter => 0 eax = 0 
eax = eax+l => eax = 1 
Counter = eax => counter = 1 


eax = eax + 1 => eax = 1 
Counter = eax => counter = 1 








上 面 两 个 线程 都 对 counter 执 行 了 上 自 增 动作 ， 但 是 最 终 的 结果 是 “1” 而 不 是 “2”"。 这 只 是 众多 错误 时 序 
情况 中 的 一 种 。 之 所 以 会 产生 这 样 的 错误 ， 就 是 因为 ++counter 的 执行 指令 并 不 是 原子 的 ， 多 个 线程 对 
counter 的 并 发 访问 造成 了 最 后 的 错误 结果 。 利 用 锁 就 可 以 保证 counter 自 增 指令 的 串 行 化 ， 如 下 所 示 : 














threadl thread2 

lock 

eax = Counter => eax =0 

eax = eax +1 => eax = 1 

Counter = eax => counter = 1 

unlock 
lock 
eax = counter => eax = 1 
eax = eax+l => eax = 2 
counter = eax => counter = 2 
unlock 











通过 加 锁 ， 可 以 视 counter 的 自 增 指令 为 “原子 指令 ”， 最 后 的 结果 终于 是 期 望 的 答案 了 。 


0.4.4 ”原子 性 











以 前 原子 被 认为 是 物理 组 成 的 最 小 单元 ， 所 以 在 计算 机 领域 ， 就 借 其 不 可 分 割 的 这 层 含 义 作 为 隐 
喻 。 对 于 计算 机 科学 来 说 ， 如 果 变 量 是 原子 的 ， 那 么 对 这 个 变量 的 任何 访问 和 更 改 都 是 原子 的 。 如 果 
操作 是 原子 的 ， 那 么 这 个 操作 将 是 不 可 分 割 的 ， 要 么 成 功 ， 要 么 失败 ， 不 会 有 任何 的 中 间 状 态 。 

















列举 一 个 原子 操作 的 例子 ， 用 户 A 向 用 户 B 转 账 1000 元 。 简 单 来 说 ， 这 里 最 起 码 有 两 个 步骤 : 





1) 用 户 A 的 账号 减少 1000 元 ; 


2) 用 户 B 的 账号 增加 1000 元 。 








如 果 在 上 述 步骤 1 结束 的 时 候 ， 转 账 发 生 了 故障 ， 比 如 电力 中 断 ， 是 否 会 造成 用 户 A 的 账号 减少 了 
1000 元 ， 而 用 户 B 的 账号 没有 变化 呢 ? 这 种 情况 对 于 原子 操作 是 不 会 发 生 的 。 当 电力 中 断 导 致 转账 操作 
进行 到 一 半 就 失败 时 ， 用 户 A 的 账号 肯定 不 会 减少 1000 元 。 因 为 这 个 操作 的 原子 性 ， 保 证 了 用 户 A 减 少 
1000 元 和 用 户 B 增 加 1000 元 ， 必 须 同时 成 立 ， 而 不 会 存在 一 个 中 间 结 果 。 至 于 这 个 操作 是 如 何 做 到 原子 
性 的 ， 可 以 参看 数据 库 的 事务 是 如 何 实现 的 一 一 原子 性 是 事务 的 一 个 特性 之 一 。 














0.4.$ 可 重 入 函数 























从 字面 上 理解 ， 可 重 入 就 是 可 重复 进入 。 在 编程 领域 ， 它 不 仅仅 意味 着 可 以 重复 进入 ， 还 要 求 在 
进入 后 能 成 功 执行 。 这 里 的 重复 进入 ， 是 指 当前 进程 已 经 处 于 该 函数 中 ， 这 时 程序 会 允许 当前 进程 的 
某 个 执行 流程 再 次 进入 该 函数 ， 而 不 会 引发 问题 。 这 里 的 执行 流程 不 仅仅 包括 多 线程 ， 还 包括 信号 处 
理 、longjump 等 执行 流程 。 所 以 ， 可 重 入 函数 一 定 是 线程 安全 的 ， 而 线程 安全 函数 则 不 一 定 是 可 重 入 函 
数 。 









































了 





从 以 上 定义 来 看 ， 很 难说 出 哪些 函数 是 可 重 入 函数 ， 但 是 可 以 很 明显 看 出 哪些 函数 是 不 可 以 重 入 
的 函数 。 当 函数 使 用 锁 的 时 候 ， 尤 其 是 互 斥 锁 的 时 候 ， 该 函数 是 不 可 重 入 的 ， 否 则 会 造成 死 锁 。 若 函 
数 使 用 了 静态 变量 ， 并 且 其 工作 依赖 于 这 个 静态 变量 时 ， 该 函数 也 是 不 可 重 入 的 ， 否 则 会 造成 该 函数 
工作 不 正常 。 




















下 面 来 看 一 个 死 锁 的 例子 代码 如 下 : 





#include <stdlib.h> 
#include <stdio.h> 
#include <pthread.h> 
#include <unistd.h> 
#include <signal.h> 
#include <sys/types.h> 
static pthread 1 mutex t mutex = PTHREAD MUTEX INITIALIZER; 
static const char * Const caller[2] = {"mutex thread", "signal handler™"}; 
static pthread 七 mutex tid; 
static pthread t sleep tid; 
static volatile int signal handler exit = 0; 
static void hold mutex (int c) 
{ 
printf("enter hold mutex [caller %s]\n", caller[c]); 
pthread mutex lock (&mutex); 
/* 这 里 的 循环 是 为 了 保证 锁 不 会 在 信号 处 理 函数 退出 前 被 释放 掉 


*/ 
while (!signal handler exit && c != 1) { 
Sleep (5); 


pthread mutex unlock(&mutex); 
printf ("leave hold mutex [caller %s]\n", caller[c]); 
} 


static void *mutex thread(void *arg) 


hold mutex (0); 
} 
static void *sleep thread (void *arg) 
{ 
Sleep (10);，; 
} 
static void signal handler (int signum) 
{ 
hold mutex (1); 
signal handler exit = 1; 
} 
int main() 
{ 
signal (SIGUSR1, signal handler); 
pthread create (&mutex tid, NULL, mutex thread, NULL); 
pthread create (&sleep tid, NULL, sleep thread, NULL); 
pthread kill (sleep - tid, SIGUSR1); 
pthread - join (mutex tid, NULL); 
pthread join(sleep tid, NULL); 
return 0; 








先 看 看 运行 结果 : 


[fgao@fgao chapter0]#gcc -g 0 8 signal mutex.c -o signal mutex -lpthread 


[fgao@fgao chapter0]#./signal mutex 
enter hold mutex [caller signal handler] 
enter hold mutex [caller mutex thread] 


中 使 用 了 pthread mutex 互 斥 











为 什么 会 死 锁 呢 ?就 是 因为 函数 hold_mutex 是 不 可 重 入 的 函数 一 一 其 
再 次 调用 就 进入 了 hold mutex。 结 果 始 终 


EE。 当 mutex thread 获 得 mutex 时 ，sleep_thread 就 收 到 了 信号 ， 
函数 无 法 返回 ， 正 第 的 程序 流程 也 无 法 继续 ， 这 就 造成 了 死 锁 。 








量 
































无 法 拿 到 mutex， 信 号 处 到 


0.4.6 ”阻塞 与 非 阻 塞 








这 里 的 阻塞 与 非 阻塞 ， 都 是 指 IO 操 作 。 在 Linux 环 境 下 ， 所 有 的 IO 系统 调用 默认 都 是 阻塞 的 。 那 么 
何谓 阻塞 呢 ? 阻塞 的 系统 调用 是 指 ， 当 进行 系统 调用 时 ， 除 非 出 错 《〈 被 信号 打 断 也 视 为 出 错 ) ， 进 程 
将 会 一 直 陷 入 内 核 态 直到 调用 完成 。 非 阻塞 的 系统 调用 是 指 无 论 IO 操 作成 功 与 个 ， 调 用 都 会 立刻 返 
回 。 

















0.4.7 ”同步 与 非 同步 





这 里 的 同步 与 非 同步 ， 也 是 指 IO 操 作 。 当 把 阻塞 、 非 阻塞 、 同 步 和 非 同步 放 在 一 起 时 ， 不 免 会 让 
人 眼花 绑 乱 。 同 步 是 否 就 是 阻塞 ， 非 同步 是 否 就 是 非 阻塞 呢 ? 实际 上 在 IO 操作 中 ， 它 们 是 不 同 的 概 
念 。 同 步 既 可 以 是 阻塞 的 ， 也 可 以 是 非 阻 塞 的， 而 第 用 的 Linux 的 IO 调用 实际 上 都 是 同步 的 。 这 里 的 同 
步 和 非 同 步 ， 是 指 IO 数 据 的 复制 工作 是 否 同步 执行 。 














以 系统 调用 read 为 例 。 阻 塞 的 read 会 一 直 陷 入 内 核 态 直到 read 返 回 : 而 非 阻塞 的 read 在 数据 未 准备 
好 的 情况 下 ， 会 直接 返回 错误 ， 而 当 有 数据 时 ， 非 阻塞 的 read 同 样 会 一 直 陷 入 内 核 态 ， 直 到 read 完 成 。 
这 个 read 就 是 同步 的 操作 ， 即 IO 的 完成 是 在 当前 执行 流程 下 同步 完成 的 。 














如 果 是 非 同步 即 异 步 ， 则 IO 操作 不 是 随 系 统 调用 同步 完成 的 。 调 用 返回 后 ，LIO 操 作 并 没有 完成 ， 
而 是 由 操作 系统 或 者 某 个 线程 负责 真正 的 IO 操作 ， 等 完成 后 通知 原来 的 线程 。 








第 1] 章 ”文件 IO 


文件 IO 是 操作 系统 不 可 或 缺 的 部 分 ， 也 是 实现 数据 持久 化 的 手段 。 对 于 Linux 来 说 ， 其 “一 切 皆 是 
文件 ”的 思想 ， 更 是 突出 了 文件 在 Linux 内 核 中 的 重要 地 位 。 本 章 主要 讲述 Linux 文 件 IO 部 分 的 系统 调 
用 。 





OO, 为 了 分 析 系 统 调用 的 实现 ， 从 本 章 开 始 会 涉及 Linux 内 核 源码 。 但 是 本 书 并 不 是 一 本 
介绍 内 核 源 码 的 书籍 ， 所 以 书 中 对 内 核 源码 的 分 析 不 会 面面俱到 。 分 析 内 核 源码 的 目的 是 为 了 更 好 地 
理解 系统 调用 ， 是 为 应 用 而 服务 的 。 因 此 ， 本 书 对 内 核 源 码 的 追踪 和 分 析 ， 只 是 浅 举 辆 止 。 








1.1 Linux 中 的 文件 


1.1.1 文件、 文件 描述 符 和 文件 表 








Linux 内 核 将 一 切 视 为 文件 ， 那 么 Linux 的 文件 是 什么 呢 ? 其 既 可 以 是 事实 上 的 真正 的 物理 文件 ， 也 
可 以 是 设备 、 管 道 ， 甚 至 还 可 以 是 一 块 内 存 。 狭 义 的 文件 是 指 文 件 系统 中 的 物理 文件 ， 而 广义 的 文件 
则 可 以 是 Linux 管 理 的 所 有 对 象 。 这 些 广 义 的 文件 利用 VFS 机 制 ， 以 文件 系统 的 形式 挂 载 在 Linux 内 核 
中 ， 对 外 提供 一 致 的 文件 操作 接口 。 





















































从 数值 上 看 ， 文 件 描述 符 是 一 个 非 负 整数 ， 其 本 质 就 是 一 个 句柄 ， 所 以 也 可 以 认为 文件 描述 符 就 
是 一 个 文件 句柄 。 那 么 何 为 句柄 呢 ? 一 切 对 于 用 户 透 明 的 返回 值 ， 即 可 视 为 句柄 。 用 户 空间 利用 文件 
描述 符 与 内 核 进 行 交互 ， 而 内 核 拿 到 文件 描述 符 后 ， 可 以 通过 它 得 到 用 于 管理 文件 的 真正 的 数据 结 
构 。 
































使 用 文件 描述 符 即 句柄 ， 有 两 个 好 处 : 一 是 增加 了 安全 性 ， 句 柄 类 型 对 用 户 完 全 透明 ， 用 户 无 法 
通过 任何 hacking 的 方式 ， 更 改 句柄 对 应 的 内 部 结果 ， 比 如 Linux 内 核 的 文件 描述 符 ， 只 有 内 核 才 能 通过 
该 值得 到 对 应 的 文件 结构 ， 二 是 增加 了 可 扩展 性 ， 用 户 的 代码 只 依赖 于 句柄 的 值 ， 这 样 实际 结构 的 类 
型 就 可 以 随时 发 生变 化 ， 与 句柄 的 映射 关系 也 可 以 随时 改变 ， 这 些 变化 都 不 会 影响 任何 现 有 的 用 户 代 
码 。 



































Linux 的 每 个 进程 都 会 维护 一 个 文件 表 ， 以 便 维护 该 进程 打开 文件 的 信息 ， 包 括 打 开 的 文件 个 数 、 
每 个 打开 文件 的 偏 移 量 等 信息 。 








1.1.2 内核 文 件 表 的 实现 


内 核 中 进程 对 应 的 结构 是 task_struct， 


钞 。 


进程 的 文件 表 保 存在 task struct->files 中 。 


其 结 


二 Sr 


构 代 码 如 下 所 





Struct files, Strucdt.4 
/* Count 为 文件 表 











上 SS tnot 的 








atomic t count; 
/* 文件 描述 符 表 


/* 
为 什么 有 两 个 


fdtable 呢 ? 这 是 内 核 的 一 种 优化 策略 。 


fdt 为 指针 ， 而 


fdtab 为 普通 变量 。 一 般 情况 下 ， 


荆 q 七 是 指向 





fdtab 的 ， 当 需要 它 的 时 候 ， 才 会 真正 动态 








情况 ， 因 此 这 样 就 可 以 避免 频繁 的 内 存 申请 。 








请 内 存 。 因 为 默认 大 小 的 文件 表 足 以 应 付 大 多 数 














这 也 是 内 核 的 常 











技巧 之 一 。 在 创建 时 ， 使 









































量 超过 默认 值 时 ， 才 会 动态 申请 内 存 。 





fdtable reu 本 于 GE 


struct fdqtable Fdtab; 


* written part on a separat 


cache lin 




















普通 的 变量 或 者 数组 ， 然 后 让 指针 指向 它 ， 作 为 默认 情况 使 


in SMP 


cacheline aligneqd in _smp 可 以 保证 


file lock 是 以 


cache 
line 对 齐 的 ， 避 免 了 


false sharing */ 


spinlock 七 file lock cacheline aligned in smp; 
/* 用 于 查找 下 一 个 空闲 的 




















fd */ 
int next fq; 
/* 保存 执行 


eXeC 需 要 关闭 的 文件 描述 符 的 位 图 


人 
struct embedded fq set close on exec init; 
/* 保存 打开 的 文件 描述 符 的 位 图 





本 
struct embedded fq set open fds init; 
/* fqd_array 为 一 个 固定 大 小 的 





fi1e 结 构 数组 。 

















Struct file 是 内 核 用 于 文 




















件 管理 的 结构 。 这 里 使 用 默认 大 小 的 数组 ， 就 是 为 了 可 以 涵盖 大 多 数 情况 ， 避 免 动 


态 分 配 


*/ 
struct file rcu * fd array[NR OPEN DEFAULT]; 
}; 





下 面 看 看 files_struct 是 如 何 使 用 默认 的 fatab 和 伺 array 的 ，init 是 Linux 的 第 一 个 进程 ， 它 的 文件 表 是 
一 个 全 局 变量 ， 代 码 如 下 : 





struct files struct init files = { 
.count © = ATOMIC INIT(1), 
“fqdt &init files.fdtab, 
.fdtab { 
.max_ fds = NR_OPEN DEFAULT, 
:Ed = &init files.fd acray[0]， 














.Close on exec = (fd set *)&init files.close on exec _ init， 
.open fds = (fd set *)&init files.open fds init, 


J 
.file lock = SPIN LOCK UNLOCKED (init task.file lock), 
}; 





init files.fdt 和 和 init files.fdtab. 和 都 分 别 指 向 了 自己 已 有 的 成 员 变 量 ， 并 以 此 作为 一 个 默认 值 。 后 面 的 
进程 都 是 从 init 进 程 fork 出 来 的 。fork 的 时 候 会 调用 dup 人 锯 ， 而 在 dup 和 中 其 代码 结构 如 下 : 








newf = kmem cache alloc (files cachep, GFP KERNEL); 
if (Inewf) 加 加 加 
goto out; 
atomic set(&newf->count, 1); 
Spin lock init(&newf->file lock); 
newf->next fd = 0; 
new fdqdt = &newf->fdtab; 
new_ fqdt->max fds = NR OPEN DEFAULT; 
new_ fdt->close on exec = (fd set *)&newf->close on exec init; 
new fdt->open fds = (fd set *)&newf->open fds init; 
new fqdt->fd = &newf->fd array[0]; 
new fdt->next = NULL 























初始 化 new_fdt， 同 样 是 为 了 计 new_fdtiinew_fdt->fd 指 向 其 本 身 的 成 员 变量 fdtab 和 fd _ array。 





全 说 明 ”/proc/pid/status 为 对 应 pid 的 进程 的 当前 运行 状态 ， 其 中 FDSize 值 即 为 当前 进程 
max fds 的 值 。 





因此 ， 初 始 状 态 下 ，files_struct、fdtable 和 files 的 关系 如 图 1-1 所 示 。 


| 




















struct file 


图 1-1 文件 表 、 文 件 描述 符 表 及 文件 结构 关系 图 


1.2 打开 文件 


1.2.1 ” open 介绍 


open 在 手册 中 有 两 个 函数 原型 ， 如 下 所 示 : 


int open (const char *pathname, int flags); 
int open (Const char *pathname, int flags, mode t mode); 





这 样 的 函数 原型 有 些 违背 了 我 们 的 直觉 。C 语 言 是 不 支持 函数 重 载 的 ， 为 什么 open 的 系统 调用 可 以 
有 两 个 这 样 的 open 原 型 呢 ? 内 核 绝 对 不 可 能 为 这 个 功能 创建 两 个 系统 调用 。 在 Linux 内 核 中 ， 实 际 上 只 
提供 了 一 个 系统 调用 ， 对 应 的 是 上 述 0 
事 呢 ? 当 我 们 调用 open 函 数 时 ， 实 际 上 调用 的 是 glibc 封 装 的 函数 ， 然 后 由 glibc 通 过 自 陷 指令 ， 进 行 真 
正 的 系统 调用 。 也 就 是 说 ， 所 有 的 系统 调用 都 要 先 经 过 glibc 才 会 进入 操作 系统 。 这 样 的 话 ， 实 际 上 是 
glibc 提 供 了 一 个 变 参 函数 open 来 满足 两 个 函数 原型 ， 然 后 通过 glibc 的 变 参 函 数 open 实 现 真 正 的 系统 调用 
来 调用 原型 二 。 


























可 以 通过 一 个 小 程序 来 验证 我 们 的 猜想 ， 代 码 如 下 : 











#include <sys/types.h> 

#include <sys/stat.h> 

#include <fcntl.h> 

#include <unistd.h> 

int main (void) 

{ 
int fd = open("test open.txt", O CREAT, 0644, "test"); 
close (fqd);，; 
return 0; 





在 这 个 程序 中 ， 调 用 open 的 时 候 ， 传 入 了 4 个 参数 ， 如 果 open 不 是 变 参 函 数 ， 就 会 报错 ， 如 “too 
many arguments to function'open”。 但 是 请 看 下 面 的 编译 输出 : 








[fgao@fgao-ThinkPad-R52 chapter2]#gcc -g -Wall 2 2 1 test open.c 
[fgao@fgao-ThinkPad-R52 chapter2]# 














没有 任何 的 警告 和 错误 。 这 束 证 实 了 我 们 的 猜想 ，open 是 glibc 的 一 个 变 参 函数 。fcntLh 中 open 函 数 
的 声明 也 确定 了 这 点 : 








extern int open ( const char * file int oflag, ...) _nonnull ((1)); 


下 面 来 说 明 一 下 open 的 参数 : 


pathname: 表示 要 打开 的 文件 路 径 。 





-flags: 用 于 指示 打开 文件 的 选项 ， 常 用 的 有 O_RDONLY、O_ WRONLY 和 O RDWR。 这 三 个 选项 





必须 有 且 只 能 有 一 个 被 指定 。 为 什么 O_RDWR! =O RDONLY|IO WRONLY 呢 ?Linux 环 境 

中 ，O_RDONLY 被 定义 为 0，O_WRONLY 被 定义 为 1， 而 O_RDWR 却 被 定义 为 2。 之 所 以 有 这 样 违反 常 
规 的 设计 遗留 至 今 ， 就 是 为 了 兼容 以 前 的 程序 。 除 了 以 上 三 个 选项 ，Linux 平 台 还 支持 更 多 的 选 

项 ，APUE 中 对 此 也 进行 了 介绍 。 















































mode: 只 在 创建 文件 时 需要 ， 用 于 指定 所 创建 文件 的 权限 位 《还 要 受到 umask 环 境 变 量 的 影 
响 ) 。 





1.2.2 ”更 多 选项 








除了 常用 的 几 个 打开 文件 的 选项 ，APUE 还 介绍 了 一 些 常 用 的 POSIX 定 义 的 选项 。 下 面 列 出 了 Linux 
平台 文 持 的 大 部 分 选项 : 





-0O_APPEND: 每 次 进行 写 操作 时 ， 内 核 都 会 先 定位 到 文件 尾 ， 再 执行 写 操作 。 


`.O_ASYNC: 使 用 异步 WO 模式 。 





-0O_CLOEXEC: 在 打开 文件 的 时 候 ， 就 为 文件 描述 符 设置 FD_CLOEXEC 标 志 。 这 是 一 个 新 的 选 
项 ， 用 于 解决 在 多 线程 下 fork 与 用 femtl 设 置 FD CLOEXEC 的 竞争 问题 。 某 些 应 用 使 用 fork 来 执行 第 三 方 
的 业务 ， 为 了 避免 泄露 已 打开 文件 的 内 容 ， 那 些 文件 会 设置 FD_CLOEXEC 标 志 。 但 是 fork 与 frntl 是 两 次 
调用 ， 在 多 线程 下 ， 可 能 会 在 fentl 调 用 前 ， 就 已 经 fork 出 子 进 程 了 ， 从 而 导致 该 文件 句柄 暴露 给 子 进 
程 。 关 于 O_CLOEXEC 的 用 途 ， 将 会 在 第 4 章 详细 讲解 。 





























`'O_CREAT: 当 文 件 不 存在 时 ， 就 创建 文件 。 








.O_DIRECT: 对 该 文件 进行 直接 WO， 不 使 用 VFS Cache。 








:0O_DIRECTORY: 要 求 打 开 的 路 径 必 须 是 目录 。 





.O_EXCL: 该 标志 用 于 确保 是 此 次 调用 创建 的 文件 ， 需 要 与 O CREAT 同 时 使 用 ， 当 文件 已 经 存在 
时 ，open 函 数 会 返回 失败 。 





`.O_LARGEFILE: 表明 文件 为 大 文件 。 
`.O_NOATIME: 读 取 文件 时 ， 不 更 新 文件 最 后 的 访问 时 间 。 


-O_NONBLOCK、O_NDELAY: 将 该 文件 描述 符 设 置 为 非 阻塞 的 〈 默 认 都 是 阻塞 的 ) 。 








'O_SYNC: 设置 为 TO 同步 模式 ， 每 次 进行 写 操作 时 都 会 将 数据 同步 到 磁盘 ， 然 后 write 才能 返回 。 


'O_TRUNC: 在 打开 文件 的 时 候 ， 将 文件 长 度 截 断 为 0， 需 要 与 O RDWR 或 O WRONLY 同 时 使 用 。 
在 写 文件 时 ， 如 果 是 作为 新 文件 重新 写 入 ， 一 定 要 使 用 O_TRUNC 标 志 ， 和 否则 可 能 会 造成 上 昌 内 容 依然 存 
在 于 文件 中 的 错误 ， 如 生成 配置 文件 、pid 文 件 等 一 一 在 第 2 章 中 ， 我 会 例 举 一 个 未 使 用 截断 标志 而 导致 
问题 的 示例 代码 。 











O 注意 “并 不 是 所 有 的 文件 系统 都 支持 以 上 选项 。 


1.2.3 open 源码 跟踪 


我 们 经 和 常 这 样 描述 “打开 一 个 文件 "， 那 么 这 个 所 谓 的 “打开 ”， 究 竟 “ 打 开 ” 了 什么 ? 内 核 在 这 个 过 程 
中 ， 又 做 了 哪些 事情 呢 ? 这 一 切 将 通过 分 析 内 核 源 码 来 得 到 答案 。 








跟踪 内 核 open 源 码 open->do_sys_open， 代 码 如 下 : 





long do sys openl(int dfd, const char user *filename, int flags, int mode) 
{ 

struct open flags op; 

/* £1ags 为 用 户 层 传递 的 参数 ， 内 核 会 天 




















£1ags 进 行 合 法 性 检查 ， 并 根据 


mode 生 成 新 的 





fl]ags 值 赋 给 


lookup */ 
int lookup = build open flags (flags, mode, &op); 
/* 将 用 户 空间 的 文件 名 参数 复制 到 内 核 空间 
































*/ 
char *tmp = getname (filename); 
int fqd = PTR_ ERR (tmp); 
if (!IS ERR(tmp)) { 
/* 未 出 错 则 申请 新 的 文件 描述 符 
2 
fd = get unused fqd flags (flags); 
if (fd >= 0) { 
/* 申请 新 的 文件 管理 结构 
file */ 
struct file xf = do filp openl(dfd, tmp, &op, lookup); 
if (IS ERR(f)) { 
put _ unused fdl(fqd); 
fd = PTR ERR(f); 
} else { 
/* 产生 文件 打开 的 通知 事件 
*#/ 


fsnotify open (f); 
/* 将 文件 描述 符 


下 d 与 文件 管理 结构 


fi1e 对 应 起 来 ， 即 安装 


4 
fd install (fd, f£); 
} 


putname (tmp); 


} 
return fd; 


} 








从 do_sys_open 可 以 看 出 ， 打 开 文件 时 ， 内 核 主 要 消耗 了 两 种 资源 ;文件 描述 符 与 内 核 管理 








EE 文件 结 














构 file。 


1.2.4 如 何 选 择 文件 描述 符 


根据 POSIX 标 准 ， 当 获取 一 个 新 的 文件 描述 符 时 ， 要 返回 最 低 的 未 使 用 的 文件 描述 符 。Linux 是 如 
何 实现 这 一 标准 的 呢 ? 


在 Linux 中 ， 通 过 do_sys_open->get unused fq flags->alloc fd (0， (fags) ) 来 选择 文件 描述 符 ， 
代码 如 下 : 





int alloc fd(unsigned start, unsigned flags) 
{ 
Struct files struct *files, s: CUrrent—>files; 
unsigned int fqd; 
int error; 
struct fdtable *fdt; 
/* files 为 进程 的 文件 表 ， 下 面 需 要 更 改 文件 表 ， 所 以 需要 先 锁 文件 表 








*/ 
spin lock(g&files->file lock); 
repeat: 
/* 得 到 文件 描述 符 表 


yA 
fat = files fdtable (files); 
/* 从 














Start 开 始 ， 查 找 未 用 的 文件 描述 符 。 在 打开 文件 时 ， 





Start 为 


0 
fd = start; 
/* files->next fq 为 上 一 次 成 功 找到 的 











正 d 的 下 一 个 描述 符 。 使 

















next fd， 可 以 快速 找到 未 











的 文 


件 描述 符 ; 


*/ 
Ef (fd < fi LESnext fd) 
fd = files->next fd; 
/* 
当 小 于 当前 文件 表 支 持 的 最 大 文件 描述 符 个 数 时 ， 利 用 位 图 找到 未 用 的 文件 描述 符 。 


























如 果 大 于 


maXx fds 怎 么 办 呢 ? 如 果 大 于 当前 支持 的 最 大 文件 描述 符 ， 那 它 肯定 是 未 























的 ， 就 不 需要 用 位 图 来 确认 了 。 








大 
/ 
if (fd < fqdt->max fds) 
fd = find next zero bit (fdt->open fds->fds bits, 
fdt->max fds, fd); 
/* expanqd files 用 于 在 必要 时 扩展 文件 表 。 何 时 是 必要 的 时 候 呢 ? 比如 当前 文件 描述 符 已 经 超过 了 当 




















前 文件 表 支 持 的 最 大 值 的 时 候 。 


*#/ 
error = éxpand files (files; fqd); 
if (error < 0) 
goto out; 
/* 
* If we needed to expand the fs array we 
* might have blocked - try again. 
内 
if (error) 
goto repeat; 


Start 小 于 


next fg 时 ， 才 需要 更 新 


next fqd， 以 尽量 保证 文件 描述 符 的 连续 性 。 


*/ 
if (start <= files->next fd) 
files->next fd = fd+ 1; 
/* 将 打开 文件 位 图 





Open fds 对 应 


荆 Q 的 位 置 置 位 


*#/ 
FD SET(fd, fdt->open fds); 
/* 根据 





flags 是 否 设 置 了 





O_CLOEXEC， 设 置 或 清除 


fdt->close on exec */ 
if (flags & O CLOEXEC) 
FD SET(fd, fdt->close on exec); 





else 
FD CLR(fd, fdt->close on exec); 
error = fd; 
大志 守 
/* Sanity check */ 
if (rcu dereference raw(fdt->fd[fd]) != NULL) { 





printk (KERN WARNING "alloc fd: slot %d not NULL!I\n", fd); 


rcu assign pointer (fdt->fdlfd], NULL); 





} 

#endif 

out: 
spin unlock (&files->file lock); 
return error; 





1.2.5 文件 描述 符合 与 文件 管理 结构 fie 





前 文 已 经 说 过 ， 内 核 使 用 和 install 将 文件 管理 结构 file 与 组合 起 来 ， 具 体操 作 请 看 如 下 代码 : 





void fd install(unsigned int fd, struct file *file) 
{ 
Struct. files strnuct, *files = CUrrent->filesy 
struct fdtable *fdt; 
spin lock(g&files->file lock); 
/* 得 到 文件 描述 符 表 





A 
fdqt = files fdtable (files); 
BUG ON (fdqt->fdq[fdq] != NULL); 
/* 





将 文件 描述 符 表 中 的 


£1i]e 类 型 的 指针 数组 中 对 应 





正 Qd 的 项 指向 


file. 


这 样 文件 描述 符 


fd 与 


fi1e 就 建立 了 对 应 关系 


*/ 
rcu assign pointer (fat->fd[lfd], file); 
spin unlock (&files->file lock); 





当 用 户 使 用 包 与 内 核 交 互 时 ， 内 核 可 以 用 得 从 fdt->fd[ 季 ] 中 得 到 内 部 管理 文件 的 结构 struct file。 


1.3 creat 简介 


creat 国 数 用 于 创建 一 个 新 文件 ， 其 等 价 于 
open (pathname，O_WRONLYIO_CREATIO_TRUNC，mode) 。APUE 介 绍 了 引入 creat 的 原因 : 


由 于 历史 原因 ， 早 期 的 Unix 版 本 中 ，open 的 第 二 个 参数 只 能 是 0、1 或 者 2。 这 样 就 没有 办 法 打开 一 
个 不 存在 的 文件 。 因 此 ， 一 个 独立 系统 调用 creat 被 引入 ， 用 于 创建 新 文件 。 现 在 的 open 函 数 ， 通 过 使 
用 O_CREAT 和 O_TRUNC 选 项 ， 可 以 实现 creat 的 功能 ， 因 此 creat 已 经 不 是 必要 的 了 。 





内 核 creat 的 实现 代码 如 下 所 示 : 





SYSCALL DEFINE2 (creat, const char _user *, pathname, int, mode) 


return sys_ open(pathname, O CREAT | O WRONLY | O TRUNC, mode); 




















这 样 就 确定 了 creat 无 非 是 open 的 一 种 封装 实现 。 


1.4 关闭 文件 
1.4.1 _ close 介绍 


close 用 于 关闭 文件 描述 符 。 而 文件 描述 符 可 以 是 普通 文件 ， 也 可 以 是 设备 ， 还 可 以 是 socket。 在 关 
闭 时 ，VFS 会 根据 不 同 的 文件 类 型 ， 执 行 不 同 的 操作 。 








下 面 将 通过 跟踪 close 的 内 核 源码 来 了 解 内 核 如 何 针对 不 同 的 文件 类 型 执行 不 同 的 操作 。 


1.4.2 close 源码 跟踪 


首先 ， 来 看 一 下 close 的 源码 实现 ， 代码 如 下 : 








SYSCALL DEFINE1 (close, unsigned int, fq) 
{ 








struct file * filp; 
/* 得 到 当前 进程 的 文件 表 





大 
/ 
struct files struct *files = current->files; 
struct fdtable *fdt; 
int retval; 
spin lock(&files->file lock); 
/* 通过 文件 表 ， 取 得 文件 描述 符 表 





A 
fqt = files fdtable (files); 
/* 参数 


fd 大 于 文件 描述 符 表 记 录 的 最 大 描述 符 ， 那 么 它 一 定 是 非法 的 描述 符 


if (fd >= fdt->max fds) 
goto out unlock; 
/* 利 




















fd 作为 索引 ， 得 到 


fi1le 结 构 指针 


*7 
filp = fdt->fd[fd]; 
/* 
检查 


fi1p 是 否 为 


NULL。 正 常情 况 下 ， 


fi1p 一 定 不 为 


NULL. 


Kd 
2 (1 ) 

goto out unlock; 
/* 将 对 应 的 


于 :1P 旱 为 


Ox/ 
rcu assign pointer (fdqt->fdq[fdq]，NULL) ; 
/* 清除 


fd 在 


ClOse_on exec 位 图 中 的 位 





人/ 
FD CLR(fd, fdt->close on exec); 
/* 释放 该 





fd， 或 者 说 将 其 置 为 


unused., 


*/ 
__ put unused fdl(files, fqd); 
spin unlock (&files->file lock); 



































/* 关闭 
file 结 构 
*/ 
retval = £1i1p. Close (filp; files)s 
/* can't restart close syscall because file tabl ntry was cleared */ 
if (unlikely (retval == -ERESTARTSYS || 
retval == -ERESTARTNOINTR || 
retval == -ERESTARTNOHAND || 
retval == -ERF START RESTARTBLOCK) ) 
retval = -EINTR; 


return retval; 

out unlock: 

“spin unlock (&files->file lock); 
return -EBADF; 于 








} 
EXPORT SYMBOL (sys close); 





”put unused 他 源码 如 下 所 示 : 





static void put unused fdl(struct files struct *files, unsigned int fd) 
{ 
/* 取得 文件 描述 符 表 


*/ 
struct fdtable *fdt = files fdtable (files); 
/* 清除 


fd 在 


Open_ fds 位 图 的 位 


4 
__FD CLR(fd, fdt->open fds); 
/* 如 果 


fd 小 于 


next fd， 重 置 


next fq 为 释放 的 


fd */ 
if (fd < files->next fd) 
files=>next fd = fd; 
} 





看 到 这 里 ， 我 们 来 回顾 一 下 之 前 分 析 过 的 alloc 和 函数 ， 就 可 以 总 结 出 完整 的 Linux 文 件 描述 符 选择 


策略 : 





Linux 选 择 文件 描述 符 是 按 从 小 到 大 的 顺序 进行 寻找 的 ， 文 件 表 中 next 锯 用 于 记录 下 一 次 开始 寻找 
的 起 点 。 当 有 空闲 的 描述 符 时 ， 即 可 分 配 。 














当 某 个 文件 描述 符 关 闭 时 ， 如 果 其 小 于 next 但 ， 则 next 他 就 重 置 为 这 个 描述 符 ， 这 样 下 一 次 分 配 
就 会 立刻 重用 这 个 文件 描述 符 。 


























以 上 的 策略 ， 总 结 成 一 句 话 就 是 “Linux 文 件 描述 符 策略 永远 选择 最 小 的 可 用 的 文件 描述 符 ”"。 一 一 
这 也 是 POSIX 标 准 规定 的 。 











其 实 我 并 不 喜欢 这 样 的 策略 。 因 为 这 样 迅速 地 重用 刚刚 释放 的 文件 描述 符 ， 容 易 引 发 难以 调试 和 
定位 的 bug 一 一 尽管 这 样 的 bug 是 应 用 层 造成 的 。 比 如 一 个 线程 关闭 了 某 个 文件 描述 符 ， 然 后 又 创建 了 一 
个 新 的 文件 描述 符 ， 这 时 文件 描述 符 就 被 重用 了 ， 但 其 值 是 一 样 的 。 如 果 有 男 外 一 个 线程 保存 了 之 前 
的 文件 描述 符 的 值 ， 那 它 就 会 再 次 访问 这 个 文件 描述 符 。 此 时 ， 如 果 是 普通 文件 ， 就 会 读 错 或 写 错 文 
件 。 如 果 是 socket， 就 会 与 错误 的 对 端 通信 。 这 样 的 错误 发 生 时 ， 可 能 并 不 会 被 察觉 到 。 即 使 发 现 了 错 
误 ， 要 找到 根本 原因 ， 也 非常 困难 。 



















































































如 果 不 重 用 这 个 描述 符 呢 ? 在 文件 描述 符 被 关闭 后 ， 创 建新 的 描述 符 且 不 使 用 相同 的 值 。 这 样 再 
次 访问 之 前 的 描述 符 时 ， 内 核 可 以 返回 错误 ， 应 用 层 可 以 更 早 地 得 知 错误 的 发 生 。 


















































虽然 造成 这 样 错误 的 原因 是 应 用 层 自 己 ,但 是 如 果 内 核 可 以 尽早 地 让 错误 发 生 ， 对 于 应 用 开发 人 





、 
AAS 











3 





因为 调试 bug 的 时 候 ，bug 距 离 造成 错误 的 地 点 越 近 ， 时 间 发 生得 越 时 ， 就 越 


员 来 说 ， 会 是 一 个 福音 。 


易 找到 根本 原因 。 这 也 是 为 什么 释放 内 存 以 后 ， 要 将 指针 置 为 NULL 的 原因 。 




















从 _put unused 人 退出 后 ，close 会 接着 调用 filp_close， 其 调用 路 径 为 flp_close->fput。 在 fput 中 ， 


会 
日 计数 为 0 时 ， 表 示 该 struct file 没 有 被 其 











对 当前 文件 struct file 的 引用 计数 减 一 并 检查 其 值 是 否 为 0。 当 引 月 
他 人 使 用 ， 则 可 以 调用 _fput 执 行 真正 的 文件 释放 操作 ， 然 后 调用 要 关闭 文件 所 属 文件 系 统 的 release 函 








数 ， 从 而 实现 针对 不 同 的 文件 类 型 来 执行 不 同 的 关闭 操作 。 


下 一 节 让 我 们 来 看 看 Linux 如 何 针 对 不 同 的 文件 类 型 ， 挂 载 不 同 的 文件 操作 函数 files_operations。 


1.4.3” 目 定义 fles operations 


不 失 一 般 性 ， 这 里 也 选择 socket 文 件 系 统 作为 示例 ， 来 说 明 Linux 如 何 挂 载 文 件 系统 指定 的 文件 操作 
函数 files_operations 。 


socket.c 中 定义 了 其 文件 操作 函数 file operations， 代 码 如 下 : 





static const struct file operations socket file ops = { 





.Owner = THIS MODULE., 
.llseek = no llseek, 

.aio read = sock aio read, 

.aio write = sock aio write, 
.Poll = sock poill, 


.unlocked ioctl = sock ioctl, 
#ifdef CONFIG COMPAT 
.compat ioctl = compat sock ioctl, 


#endif 
.mmap = sock mmap, 
.open = sock no_ open, /* special open code to disallow open via /proc */ 
.release = sock close, 
.fasync = sock fasync, 


.Sendpage = sock sendpage, 
.splice write = generic splice sendpage, 
.splice read = sock splice read, 





函数 sock alloc_file 用 于 申请 socket 文 件 描 述 符 及 文件 管理 结构 fle 结 构 。 它 调用 alloc_file 来 申请 管 
理 结构 fle， 并 将 socket file_ ops 作 为 参数 ， 如 下 所 示 : 

















file = alloc file(&path，FMODE READ | FMODE WRITE， 
&socket file ops); 





进入 alloc_file， 来 看 看 如 下 代码 : 





struct file *alloc filel(struct path *path, fmode t mode, 
const struct file operations *fop) 
{ 


struct file *file; 
/* 申请 一 个 





file */ 
filé = get empty filp(); 
if (!file) 


return NULL; 
file->f path = *path; 
file->f mapping = path->dentry->d inode->i mapping; 
file->f mode = mode; a 
/* 将 自 定义 的 文件 操作 函数 赋 给 





file->f op */ 
file->f op = fop; 





在 初始 化 file 结 构 的 时 候 ，socket 文 件 系统 将 其 自 定义 的 文件 操作 冉 给 了 file->f op， 从 而 实现 了 在 





VEFS 中 可 以 调用 socket 文 件 系统 自 定 义 的 操作 。 


1.4.4 ”遗忘 close 造 成 的 问题 








我 们 只 需要 关注 close 文 件 的 时 候 内 核 做 了 哪些 事情 ， 就 可 以 确定 遗忘 close 会 带 来 什么 样 的 后 果 ， 
如 下 : 


:文件 描述 符 始 终 没 有 被 释放 。 


用 于 文件 管理 的 某 些 内 存 结构 没有 被 释放 。 





对 于 普通 进程 来 说 ， 即 使 应 用 忘记 了 关闭 文件 ， 当 进程 退出 时 ，Linux 内 核 也 会 自动 关闭 文件 ， 释 
放 内 存 〈 详 细 过 程 见 后 文 ) 。 但 是 对 于 一 个 常 驻 进程 来 说 ， 问 题 就 变 得 严重 了 。 











先 看 第 一 种 情况 ， 如 果 文 件 描述 符 没 有 被 释放 ， 那 么 再 次 申请 新 的 描述 符 时 ， 就 不 得 不 扩展 当前 
的 文件 表 了 ， 代 码 如 下 : 




















int expand files(struct files struct *files, int nr) 


struct fdtable *fdt; 
fdt = files fdtable (files); 
7 
* N.B. For clone tasks sharing a files structure, this test 
* will limit the total number of files that can be opened. 
去 / 

if (nr >= rlimit (RLI IT NOFILE)) 

return -EMFILE; 





/* Do we need to expand? */ 
if (nr < fdt->max fds) 
return 0; 
/* Can we expand? */ 

if (nr >= sysctl1 nr open) 
return -EMFILE; 
/* All good, so we try */ 

return expand fdtable (files, nr); 








从 上 面 的 代码 可 以 看 出 ， 在 扩展 文件 表 的 时 候 ， 会 检查 打开 文件 的 个 数 是 否 超出 系统 的 限制 。 如 
果 文 件 描述 符 始终 不 释放 ， 其 个 数 迟 早 会 到 达 上 限 ， 并 返回 EMFILE 错 误 〈 表 示 Too many open 
files (POSIX.1) ) 。 








再 看 第 二 种 情况 ， 即 文件 管理 的 某 些 内 存 结构 没有 被 释放 。 仍 然 是 查看 打开 文件 的 代码 ， 代 码 如 
下 其 中 ，get empty filp 用 于 获得 空闲 的 file 结 构 。 














struct file *get empty filp (void) 
{ 


const 和 七 ze 上 GEQ *Cred = Current cred(); 
static long old max; 

Struet. FLLS* E> 

/* 


* Privileged users can go above max files 
去 人/ 


/* 这 里 对 打开 文件 的 个 数 进行 检查 ， 非 特权 用 户 不 能 超过 系统 的 限制 


4 
if (get nr files() >= files stat.max files && !capable (CAP SYS ADMIN)) { 
/* 
再 次 检查 


Per CPU 的 文件 个 数 的 总 和 


为 什么 要 做 两 次 检查 呢 。 后 文 会 详细 介绍 


7 
if (percpu counter sum positive(&nr files) >= files stat.max files) 
goto over; 
} 
/* 未 到 达 上 限 ， 申 请 一 个 新 的 





fi 1 Ee 结 构 


f = kmem cache zalloc (filp cachep, GFP KERNEL); 
if (f == NULL) 和 

goto fail; 
/* 增加 


fi1e 结 构 计 数 


党 

/ 
percpu counter inc(g&nr files); 
f->f ored = get cred(cred)y 
if (security file alloc(E)) 

goto fail sec; 

INIT LIST HEAD(&f->f u.fu list) 
atomic long set(&f->f count, 1) 
rwlock init(&f->f owner.lock); 
spin lock init (&f->f lock); 
eventpoll init file(f£); 








F 
了 


/* f->f version: 0 */ 
return 三; 

Over: 
/* 用 完了 




















file 了 配额， 打印 
] Og 报错 


大 
/ 
/* Ran out of filps - report that */ 
if (get nr files() > old max) { 
pr info("VFS: file-max limit %lu reached\n", get max files()); 
Old max = get nr files(); 
} 
goto fail; 
fail sec: 
file free(f); 
fail; 本 
return NULL; 
} 





下 面 来 说 说 为 什么 上 面 的 代码 要 做 两 次 检查 一 这 也 是 我 们 学 习 内 核 代码 的 好 处 之 一 ， 可 以 学 到 
很 多 的 编程 技巧 和 设计 思路 。 

















对 于 file 的 个 数 ，Linux 内 核 使 用 两 种 方式 来 计数 。 一 是 使 用 全 局 变量 ， 另 外 一 个 是 使 用 percpu 变 
量 。 更 新 全 局 变量 时 ， 为 了 避免 竞争 ， 不 得 不 使 用 锁 ， 所 以 Linux 使 用 了 一 种 折 中 的 解决 方案 。 当 














由 














percpu 变 量 的 个 数 变化 不 超过 正 负 percpu_counter_ batch〈 默 认为 32) 的 范围 时 ， 就 不 更 新 全 局 变量 。 这 
样 就 减少 了 对 全 局 变量 的 更 新 ， 可 是 也 造成 了 全 局 变量 的 值 不 准确 的 问题 。 于 是 在 全 局 变量 的 file 个 数 


超过 限制 时 ， 会 再 对 所 有 的 percpu 变 量 求 和 ， 再 次 与 系统 的 限制 相 比 较 。 想 了 解 这 个 计数 手段 的 详细 信 















































息 ， 可 以 阅读 percpu_counter add 的 相关 代码 。 


1.4.5 如 何 查 找 文 件 资源 泄漏 





























在 前 面 的 小 节 中， 我们 看 到 了 常 驻 进程 忘记 关闭 文件 的 危害 。 可 是 ， 软 件 不 可 能 不 出 现 pug， 如 果 常 驻 进程 程序 真 的 出 现 了 这 
样 的 问题 ， 如 何 才能 快速 找到 根本 原因 呢 ? 通过 审查 打开 文件 的 代码 ? 时 间 长 效率 低 。 那 是 否 还 有 其 他 办 法 呢 ? 下 面 我 们 来 介绍 
一 种 能 快速 查找 文件 资源 泄漏 的 方法 。 
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首先 ， 创 建 一 个 “错误 ”的 程序 ， 代 码 如 下 : 








#include <stdlib.h> 
#include <stdio.h> 
#include <unistd.h> 
int main (void) 
{ 
int cnt = 0; 
while (1) { 
char name[64]; 
snprintf (name, sizeof (name),"%d.txt", cnt); 
int fd = creat (name, 644); 
Sleep (10); 
生 二 Gat 
} 


return 0; 




















在 这 段 代码 的 循环 过 程 中 ， 打 开 了 一 个 文件 ， 但 
一 段 时 间 : 








没有 被 关闭 ， 以 此 来 模拟 服务 程序 的 文件 资源 泄漏 ， 然 后 让 程序 运行 








ou 























[fgao@fgao chapterl]#./hold file & 
[1] 3000 














接 下 来 请 出 利器 lsof， 查 看 相关 信息 ， 如 下 所 示 : 








[fgao@fgao chapter1]#1sof -p 3000 
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME 


*OUt 3000 fgao 6w REG 253,2 
Out 3000 fgao 7W REG 253,2 
out 3000 fgao 8w REG 253,2 
”Out 3000 fgao 9w REG 253,2 


327891 /home/fgao/works/my git codes/my books/understanding apue/sample codes/chapter1/3.txt 
327892 /home/fgao/works/my_git codes/my books/understanding apue/sample codes/chapter1/4.txt 


a.out 3000 fgao cwd DIR 253;2 4096 1321995 /home/fgao/works/my git codes/my books/understanding apue/sample codes/chapterl 

Ut 3000 fgao rtd DIR 253;1 4096 2 8 

a.out 3000 fgao txt REG 253,2 6115 1308841 /home/fgao/works/my _ git codes/my books/understanding apue/sample codes/chapterl/a.out 
a.out 3000 fgao mem REG 253,1 157200 1443950 /lib/ld-2.14.90.so 

a.out 3000 fgao mem REG 253,1 2012656 1443951 /lib/libc-2.14.90.so 

a.out 3000 fgao Ou CHR. L363 Qt0 6 /dev/pts/3 

a.out 3000 fgao 1u CHR 136,3 0t0 6 /dev/pts/3 

a.out 3000 fgao 2u CHR 136,3 0t0 6 /dev/pts/3 

a.out 3000 fgao 3w REG 253,2 0 1309088 /home/fgao/works/my_git codes/ my books/understanding apue/sample codes/chapter1/0.txt 
a.out 3000 fgao 4w REG 253,2 0 1312921 /home/fgao/works/my_git codes/my books/understanding apue/sample codes/chapterl/1.txt 
a.out 3000 fgao 5w REG 253,2 0 1327890 /home/fgao/works/my_git codes/my books/understanding apue/sample codes/chapterl1/2.txt 
a 

a 

a 

a 





327893 /home/fgao/works/my_git codes/my books/understanding apue/sample codes/chapter1/5.txt 
327894 /home/fgao/works/my_ git codes/my books/understanding apue/sample codes/chapter1/6.txt 


Oooo 


























从 lsof 的 输出 结果 可 以 清晰 地 看 出 ，hold_file 打 开 的 哪些 文件 没有 被 和 关闭。 其实 从 /proc/3000/ 弓 中 也 可 以 得 到 类 似 的 结果 。 但 是 
lsof 拥 有 更 多 的 选项 和 功能 〈 如 指定 某 个 目录 ) ， 可 以 应 对 更 复杂 的 情况 。 有 具体 细节 就 需要 读者 自行 阅读 lsof 的 说 明文 档 了 。 
















































































1.$ ”文件 偏 移 


文件 偏 移 是 基于 茶 个 打开 文件 来 说 的 ， 一 般 情况 下 ， 读 写 操作 都 会 从 当前 的 偏 移 位 置 开 始 读 写 
《所 以 read 和 write 都 没有 显 式 地 传 入 偏 移 量 ) ， 并 且 在 读 写 结束 后 更 新 偏 移 量 。 











1.$.1 “lseek 简 介 


lseek 的 原型 如 下 : 


off 七 lseek(int fd, off t offset, int whence); 
该 函数 用 于 将 包 的 文件 偏 移 量 设置 为 以 whence 为 起 点 ， 偏 移 为 ofgset 的 位 置 。 其 中 whence 可 以 为 三 


个 值 : SEEK SET、SEEK_ CUR 和 SEEK_ END， 分别 表 示 为 “文件 的 起 始 位 置 ^ “文件 的 当前 位 置 ? 和 “ 文 
件 的 末尾 ”， 而 offgset 的 取 值 正 负 均 可 。lseek 执 行 成 功 后 ， 会 返回 新 的 文件 偏 移 量 。 











在 Linux 3.1 以 后 ，Linux 又 增加 了 两 个 新 的 值 : SEEK DATA 和 SEEK _ HOLE， 分 别 用 于 查找 文件 中 
的 数据 和 空洞 。 





1.$.2 ”小心 lseek 的 返回 值 








对 于 Linux 中 的 大 部 分 系统 调用 来 说 ， 如 果 返 回 值 是 负数 ， 那 它 一 般 都 是 错误 的 ， 但 是 对 于 lseek 来 
说 这 条 规则 不 适用 。 且 看 lseek 的 返回 值 说 明 : 


© 注意 ” 当 ]seek 执 行 成 功 时 ， 它 会 返回 最 终 以 文件 起 始 位 置 为 起 点 的 偏 移 位 置 。 如 果 出 错 ， 
则 返回 -1， 同 时 errno 被 设置 为 对 应 的 错误 值 。 





也 就 是 说 ， 一 般 情况 下 ， 对 于 普通 文件 来 说 ，1lseek 都 是 返回 非 负 的 整数 ， 但 是 对 于 某 些 设备 文件 
来 说 ， 是 允许 返回 负 的 偏 移 量 。 因 此 要 想 判 断 lseek 是 否 真正 出 错 ， 必 须 在 调用 lseek 前 将 errno 重 置 为 0， 
然后 再 调用 lseek， 同 时 检查 返回 值 是 否 为 -1 及 errno 的 值 。 只 有 当 两 个 同时 成 立时 ， 才 表明 lseek 真 正 出 
若 了 。 














因为 这 里 的 文件 偏 移 都 是 内 核 的 概念 ， 所 以 lseek 并 不 会 引起 任何 真正 的 VO 操作 。 


1.5.3 ”lseek 源 码 分 析 


lseek 的 源码 位 于 read_write.c 中 ， 如 下 : 








SYSCALL DEFINE3 (lseek, unsigned int, fd, off t, offset, unsigned int, origin) 
{ 








off t retval; 
struct file * file; 
int fput needed; 











retval = -EBADF; 
/* 根据 

fd 得 到 

file 指 针 

*/ 
file = fget light (fd, &fput needed); 
if (!file) 

goto bad; 

retval = -EINVAL; 
/* 对 初始 位 置 进行 检查 ， 目 前 


1 inux 内 核 支 持 的 初始 位 置 有 


1 .5 .1 节 中 提 到 的 五 个 值 





*/ 
if (origin <= SEEK MAX) { 

loff 七 res = vfs llseek(file, offset, origin); 

/* 下 面 这 段 代 码 ， 先 使 





























res 来 给 


retval 赋 值 ， 然 后 再 次 判断 


大 们 如 


retval 相 等 。 为 什么 会 有 这 样 的 逻辑 呢 ? 什么 时 候 两 者 会 不 相等 呢 ? 


retval 与 


reS 的 位 数 不 相 等 的 情况 下 。 


retval 的 类 型 是 


off t-> kernel off t->long 





ZeS 的 类 型 是 





loff 七 -> kernel off 七 ->Jong long; 
在 


32 位 机 上 ， 前 者 是 


32 位 ， 而 后 者 是 


64 位 。 当 


reS 的 值 超过 了 


retval 
的 范围 时 ， 两 者 将 会 不 等 。 即 实际 偏 移 量 超 过 了 





1]ong 类 型 的 表示 范围 。 











yy 
retval = res; 
if (nes 1= (LT60ff t)retval) 
retval = -EOVERFLOW; /* LFS: should only happen on 32 bit platforms */ 











} 

fput light (file, fput needed); 
bad: 

return retval; 
} 





然后 进入 vfs llseek， 代 码 如 下 : 





LoOff t vfs. LLseek(Sstruct file *fiLle, J60ff t offset, Int Origin) 
{ 

loff 七 (*fn) (struct file *, loff t, int); 

/* 默认 的 


工 Seek 操 作 是 


no_llseek, 当 


fi1e 没 有 对 应 的 


工 Seek 实 现时 ， 就 

















会 调 





no_11seek， 并 返回 








ESPIPE 错 误 








4 
fn = no llseek; 
if (file->f mode & FMODE LSEEK) { 
if (file->f op && file->f op->llseek) 
fn = file->f op->llseek; 
上 


return fn(file offset, origin); 





当 file 文 持 llseek 操 作 时 ， 就 会 调用 具体 的 llseek 函 数 。 在 此 ， 选 择 default_ llseek 作 为 实例 ， 代 码 如 
下 : 





loff 七 default llseek(struct file *file, loff t offset, int origin) 
{ 

struct inode *inode = file->f path.dentry->d inode; 

loff t retval; i 

mutex lock(&inode->i mutex); 

Switch (origin) { 

case SEEK END: 
/* 最 终 偏 移 等 于 文件 的 大 小 加 上 指定 的 偏 移 量 

















大 
/ 
offset += 1 size read(inode); 
break; 
Case SEEK_ CUR: 
/* offset 为 


0 时 ， 并 不 改变 当前 的 偏 移 量 ， 而 是 直接 返回 当前 偏 移 量 


*/ 
if (offset == 0) { 
retval = file->f pos; 
aoto Gu; 
} 
/* 车 
Offset 不 为 


则 最 终 偏 移 等 于 指定 偏 移 加 上 当前 偏 移 


offséet. += filé->f pos; 
break; 
Case SEEK DATA: 














* In the generic case th ntire file is data, so as 

* long as offset isn't at the end of the file then the 
* offset is data. 

雪人 

/* 如 注释 所 言 ， 对 于 一 般 文件 ， 只 要 指定 偏 移 不 超过 文件 大 小 ， 那 么 指 








定 偏 移 的 位 置 就 是 数据 位 置 


4 
if (offset. >= inode->i sizé) 1 
retval = -ENXIO; 
goto out; 








case SEEK HOLE: 














* There is a virtual hole at the end of the file, so 
* as, long as, offset isn't 1 sizé or Jarger, return 
* 1 size,., 
*/ 
/* 只 要 指定 偏 移 不 超过 文件 大 小 ， 那 么 下 一 个 空洞 位 置 就 是 文件 的 末尾 





A 
if (offset >= inode->i size) { 
retval = -ENXIO; 
ooto: SEE 





} 
offset = inode-=>i size; 
break; 
} 
retval = -EINVAL; 
/* 对 于 一 般 文件 来 说 ， 最 终 的 





Offset 必 须 大 于 或 等 于 


0,， 或 者 该 文件 的 模式 要 求 只 能 产生 无 符号 的 偏 移 量 。 否 则 就 会 报错 








4 
if (offset >= 0 || unsigned offsets (file)) { 
/* 当 最 终 偏 移 不 等 于 当前 位 置 时 ， 则 更 新 文件 的 当前 位 置 
*#/ 
i "(OffSet |= 失主] 全 一生 BOs) 并 
file->f pos = offset; 
file->f Version = 0; 
retval = offset; 
} 
Suts 


mutex unlock(&inode->i mutex); 
return retval; 





1.6 读 取 文件 


Linux 中 读 取 文件 操 作 时 ， 最 常用 的 就 是 read 函 数 ， 其 原型 如 下 : 





ssize 七 read(int fd, void *buf, size t Count)s; 








read 党 试 从 乌 中 读 取 count 个 字 贡 到 buft 中 ， 并 返回 成 功 读 取 的 字 节 数 ， 同 时 将 文件 偏 移 向 前 移动 相 
同 的 字 节 数 。 返 回 0 的 时 候 则 表示 已 经 到 了 “文件 尾 "。read 还 有 可 能 读 取 比 count 小 的 字 节 数 。 





使 用 read 进 行 数 据 读 取 时 ， 要 注意 正确 地 处 理 错误 ， 也 是 说 read 返 回 -1 时 ， 如 果 errno 为 EAGAIN、 
EWOULDBLOCK 或 EINTR， 一 般 情 况 下 都 不 能 将 其 视 为 错误 。 因 为 前 两 者 是 由 于 当前 包 为 非 阻 塞 且 没 
有 可 读数 据 时 返回 的 ， 后 者 是 由 于 read 被 信号 中 断 所 造成 的 。 这 两 种 情况 基本 上 都 可 以 视 为 正常 情况 。 











= 














1.6.1 read 源码 跟踪 


先 来 看 看 read 的 源码 ， 代 码 如 下 : 











SYSCALL DEFINE3 (read, unsigned int, fd, char user *, buf, size t, count) 
{ 








struct file *file; 
ssize 七 ret = -EBADF; 
int fput needed; 

/* 通过 文件 描述 符 





正 d 得 到 管理 结构 


file */ 
file = fget light (fd, &fput needed); 
if (file) { 加 
/* 得 到 文件 的 当前 偏 移 量 


loff t pos = file pos read(file); 
/* 利 























YVES 进行 真正 的 





read */ 
ret = vfs readl(file, buf, count, &pos); 
/* 更 新 文件 偏 移 量 





A 
file pos write(file, pos); 
/* 归还 管理 结构 

















file， 如 有 必要 ， 就 进行 引用 计数 操作 








*/ 
fput light (file, fput needed); 
} 


Eeturn. Eet? 





再 进入 vfs_read， 代 码 如 下 : 





ssize 七 vfs read(struct file *file, char user *buf, size t count, loff 七 *pos) 
{ 

SSize. t ret; 

/* 检查 文件 是 否 为 读 取 打 开 


4 
if (! (file->f mode & FMODE READ)) 
return -EBADF; 
/* 检查 文件 是 否 支持 读 取 操作 

















if (!file->f op 


|| (!file->f op->read && !file->f op->aio read)) 


return -EINVAL; 











/* 检查 用 户 传递 的 参数 











jbuf 的 地 址 是 否 可 写 


迷 / 





if (unlikely(!access ok (VERIFY WRITE, buf, count))) 
return -EFAULT; 
/* 检查 要 读 取 的 文件 范围 实际 可 读 取 的 字 节 数 


A 








ret = rw verify area (READ, file, pos, count); 


if (ret >= 0) 1 


/* 根据 上 面 的 结构 ， 调 整 要 读 取 的 字 节 数 





WA 


Count = rety 


/* 
如 果 定 义 


reaq 操 作 ， 则 执行 定义 的 


read 操 作 


如 果 没 有 定义 

















zead 操 作 ， 则 调 





do_sync _reaqd- 其 利用 异步 


aio_reag 来 完成 同步 的 


f_op->read) 
file->f op->read(file, buf, count, pos); 


do _ sync read(file, buf, count, pos); 
0) { 


/* 读 取 了 一 定 的 字 节 数 ， 


reaQ 操 作 。 
*#)/ 
if (file-> 
ret = 
else 
ret = 
if (ret > 
进行 通知 操作 
去 / 


fsnotify _ access (file); 


/* 增加 进程 读 取 字 节 的 统计 计数 


*/ 
adqd rchar(current, ret); 











} 
/* 增加 进程 系统 调用 的 统计 计数 








4 
inc syscr (current); 


} 


tt St 





上 面 的 代码 为 read 公 共 部 分 的 源码 分 析 ， 具 体 的 读 取 动作 是 由 实际 的 文件 系统 决定 的 。 


1.6.2 ”部 分 读 取 





前 文中 介绍 read 可 以 返回 比 指定 count 少 的 字 节 数 ， 那 么 什么 时 候 会 发 生 这 种 情况 呢 ? 最 直接 的 想 
法 是 在 色 中 没有 指定 count 大 小 的 数据 时 。 但 这 种 情况 下 ， 系 统 是 不 是 也 可 以 阻塞 到 满足 count 个 字 节 的 
数据 昵 ? 那么 内 核 到 底 采 取 的 是 哪 种 策略 呢 ? 

















让 我 们 来 看 看 socket 文 件 系 统 中 UDP 协议 的 read 实 现 : socket 文 件 系统 只 定义 了 aio_ read 操作 ， 没 有 
定义 普通 的 read 函 数 。 根 据 前 文 ， 在 这 种 情况 下 do_sync_read 会 利用 aio_read 实 现 同步 读 操作 。 











其 调用 链 为 Sock aio read->do sock read-> sock recvmsg-> sock recvmsg nose->udp recvmsg， 代 


码 如 下 所 示 : 





int udp recvmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg, 
size t len, int noblock, int flags, int *addr len) 


ulen = skb->len - sizeof (struct udphdr); 
copied = len; 
if (copied > ulen) 

copied = ulen; 


当 UDP 报 文 的 数据 长 度 小 于 参数 len 时 ， 就 会 只 复制 真正 的 数据 长 度 ， 那 么 对 于 read 操 作 来 说 ， 
回 的 读 取 字 节 数 自然 就 小 于 参数 count 了 。 


看 到 这 里 ， 是 否 已 经 得 到 本 小 节 开 头 部 分 问题 的 答案 了 呢 ? 当 伺 中 的 数据 不 够 count 大 小 时 ，read 会 
返回 当前 可 以 读 取 的 字 节 数 ? 很 可 惜 ， 答 案 是 否定 的 。 这 种 行为 完全 由 具体 实现 来 决定 。 即 使 同 为 
socket 文 件 系统 ，TCP 套 接 字 的 读 取 操作 也 会 与 UDP 不 同 。 当 TCP 的 人 包 的 数据 不 足 时 ，read 操 作 极 可 能 会 
阻塞 ， 而 不 是 直接 返回 。 注 : TCP 是 否 阻 寒 ， 取 决 于 当前 缓存 区 可 用 数据 多 少 ， 要 读 取 的 字 节 数 ， 以 及 

套 接 字 设 置 的 接收 低 水 位 大 小 。 











因此 在 调用 read 的 时 候 ， 只 能 根据 read 接 口 的 说 明 ， 小 心 处 理 所 有 的 情况 ， 而 不 能 主观 腾 测 内 核 的 
实现 。 比 如 本 文中 的 部 分 读 取 情 况 ， 阻 塞 和 直接 返回 两 种 策略 同时 存在 。 





1.7 写 入 文件 


Linux 中 写 入 文件 操作 ， 最 第 用 的 就 是 write 函数 ， 其 原型 如 下 : 





ssize 七 Write (int fd, const void *buf, size 七 count); 





write 尝 试 从 buf 指 向 的 地 址 ， 写 入 count 个 字 节 到 文件 描述 符 身 中 ， 并 返回 成 功 写 入 的 字 节 数 ， 同 时 
将 文件 偏 移 向 前 移动 相同 的 字 节 数 。writef 有 可 能 写 入 比 指定 count 少 的 字 节 数 。 





1.7.1 write 源码 跟踪 


write 的 源码 与 read 的 很 相似 ， 位 于 read_write.c 中 ， 代 码 如 下 ; 














SYSCALL DEFINE3 (write, unsigned int, fd, const char user *, buf, 
size t, Count) 
( 


struct file *file; 


























ssize 七 ret = ~EBADF; 
int fput needed; 
/* 得 型 
file 管理 结构 指针 
* 
file = fget light(fd, &fput needed); 
if (file) { 
/* 得 到 当前 的 文件 偏 移 
* 
loff 七 pos = file pos read (file); 
/* 利 
VFS 写 入 
*/ 
ret = vfs write(file, buf, count, &pos); 
/* 更 新 文件 偏 移 量 
#/ 
file pos write(file, pos); 
/* 释放 文件 管理 指针 
file */ 


fput light (file, fput needed); 
} 


return 天 本 





进入 vfs_write， 代 码 如 下 : 





ssize t vfs write (Struct file *file, const char user *buf, size t count, loff t *pos) 
{ 

SSlZE t Let 

/* 检查 文件 是 否 为 写 入 打开 


本 
if (!(file->f mode & FMODE _ WRITE) ) 
return -EBADF; 
/* 检查 文件 是 否 支持 打开 操作 

















* 
if (!file->f op || (!file->f op->write && !file->f op->aio write)) 
return -EINVAL; 











/* 检查 用 户 给 定 的 地 址 范围 是 否 可 读 取 




















if (unlikely(!access ok (VERIEY READ, buf, count))) 





return ~EFAULT; 
/* 
验证 文件 从 





POS 起 始 是 否 可 以 写 入 


COUD 芋 个 字 节 数 


并 返回 可 以 写 入 的 字 节 数 





*#/ 
ret = rw verify area (WRITE, file, pos, count); 
if (ret >= 0) { 

/* 更 新 写 入 字 节 数 





*/ 
count = rets 
/* 
如 果 定 义 


WEIte 操 作 ， 则 执行 定义 的 


WEI 七 e 操 作 


如 果 没 有 定义 

















WIite 操 作 ， 则 调 




















do_sync_write- 其 利用 异步 


aio_write 来 完成 同步 的 


WIite 操 作 


A 
if (file->f op->write) 


ret = file->f op->write(file, buf, count, pos); 


else 


ret = do sync writel(file, buf, count, pos); 


if (ret > 0) { 
/* 写 入 了 一 定 的 字 节 数 ， 


进行 通知 操作 


汪 冰 
fsnotify modify(file); 
/* 增加 进程 读 取 字 节 的 统计 计数 
*/ 
adqd wchar (current, ret); 
} 
/* 增加 进程 系统 调用 的 统计 计数 
*/ 


inc syscw(current); 


Ceturn. eet 














write 同样 有 部 分 写 入 的 情况 ， 这 个 与 read 类 似 ， 都 是 由 具体 实现 来 决定 的 。 在 此 就 不 再 深入 探讨 
write 的 部 分 写 入 的 情况 了 。 





1.7.2 ”追加 写 的 实现 





前 面 说 过 ， 文 件 的 读 写 操作 都 是 从 当前 文件 的 偏 移 处 开始 的 。 这 个 文件 偏 移 量 保 存在 文件 表 中 ， 
而 每 个 进程 都 有 一 个 文件 表 。 那 么 当 多 个 进程 同时 写 一 个 文件 时 ， 即 使 对 write 进行 了 锁 保 护 ， 在 进行 
串 行 写 操作 时 ， 文 件 依然 不 可 避免 地 会 被 写 乱 。 根 本 原因 就 在 于 文件 俩 移 量 是 进程 级 别 的 。 




















当 使 用 O_APPEND 以 追加 的 形式 来 打开 文件 时 ， 每 次 写 操作 都 会 先 定位 到 文件 末尾 ， 然 后 再 执行 
写 操作 。 

Linux 下 大 多 数 文件 系统 都 是 调用 generic file aio write 来 实现 写 操作 的 。 在 generic file_aio_write 
中 ， 有 如 下 代码 : 





mutex lock(&inode->i mutex); 

blk start plug(&plug); 

ret = generic file aio write(iocb, iov, nr segs, &iocb->ki pos); 
mutex unlock(&inode->i mutex); 








这 里 有 一 个 关键 的 语句 ， 就 是 使 用 mutex_lock 对 该 文件 对 应 的 inode 进 行 保护 ， 然 后 调用 


generic file aio write->generic write check。 其 部 分 代码 如 下 : 


if (file->f flags & O APPEND) 
*pos = 1 size read (inode); 








上 面 的 代码 中 ， 如 果 发 现 文 件 是 以 追加 方式 打开 的 ， 则 将 从 inode 中 读 取 到 的 最 新 文件 大 小 作为 偏 
移 量 ， 然 后 通过 ”generic_file aio_ write 再 进行 写 操作 ， 这 样 就 能 保证 写 操作 是 在 文件 末尾 追加 的 。 


18， 文 必 的 尿 子 全 与 





使 用 O_APPEND 可 以 实现 在 文件 的 末尾 原子 追加 新 数据 ，Linux 还 提供 pread 和 pwrite 从 指定 偏 移 位 
置 读 取 或 写 入 数据 。 





它们 的 实现 很 简单 ， 代 码 如 下 : 





SYSCALL DEFINE (pread64) (unsigned int fd, char _user *buf, 
Size. t Count, loff 七 Pos) 





{ 
struct file *file; 
ssize 七 ret = ~EBADF; 
int fput needed; 
if (pos < 0) 
return -EINVAL; 
file = fget light (fd, &fput needed); 
if (file) { 
ret = -ESPIPE; 
if (file->f mode & FMODE PREAD) 
ret = vfs read(file, buf, count, &pos); 
fput light (file, fput needed); 























} 


Ee ety 





看 到 这 段 代码 ， 是 不 是 有 一 种 似曾相识 的 感觉 ? 让 我 们 再 来 回顾 一 下 read 的 实现 ， 代 码 如 下 所 示 。 





/* 得 到 文件 的 当前 偏 移 量 


A 
loff 七 pos = file pos read (file); 
/* 利 























VS 进行 真正 的 


read */ 
ret = vfs readl(file, buf, count, &pos); 
/* 更 新 文件 偏 移 量 





w/ 
file pos write(file, pos); 





这 就 是 它 与 read 的 主要 区 别 。pread 不 会 从 文件 表 中 获取 当前 偏 移 ， 而 是 直接 使 用 用 户 传递 的 偏 移 
量 ， 并 且 在 读 取 完 毕 后 ， 不 会 更 改 当前 文件 的 偏 移 量 。 











pwrite 的 实现 与 pread 类 似 ， 在 此 就 不 再 重复 描述 了 。 


1.9 文件 描述 符 的 复制 

















Linux 提 供 了 三 个 复制 文件 描述 符 的 系统 调用 ， 分 别 为 : 


int qup (int oldfqd); 
int dup2(int oldfd, int newfdqd); 
int dup3(int oldfd, int newfd, int flags); 





其 中 : 





“dup 会 使 用 一 个 最 小 的 未 用 文件 描述 符 作为 复制 后 的 文件 描述 符 。 


dup2 是 使 用 用 户 指 定 的 文件 描述 符 newfd 来 复制 oldfd 的 。 如 果 newfd 己 经 是 打开 的 文件 描述 
符 ，Linux 会 先 关 闭 new 伺 ， 然 后 再 复制 oldfa。 





.对 于 dup3， 只 有 定义 了 feature 宏 ” GNU SOURCE” 才 可 以 使 用 ， 它 比 dup2 多 了 一 个 参数 ， 可 以 指定 
标志 一 一 不 过 目前 仅仅 支持 O_ CLOEXEC 标 志 ， 可 在 newfd 上 设置 O CLOEXEC 标 志 。 定 义 dup3 的 原因 与 
open 类 似 ， 可 以 在 进行 dup 操 作 的 同时 原子 地 将 乌 设 置 为 0 CLOEXEC， 从 而 避免 将 文件 内 容 暴 露 给 子 进 


程 。 





























为 什么 会 有 dup、dup2、dup3 这 种 像 兄 弟 一 样 的 系统 调用 呢 ? 这 是 因为 随 着 软件 工程 的 日 益 复 杂 ， 
己 有 的 系统 调用 已 经 无 法 满足 需求 ， 或 者 存在 安全 隐患 ， 这 时 ， 就 需要 内 核 针 对 己 有 问题 推出 新 的 接 
口 。 





























话说 在 很 久 以 前 ， 程 序 员 在 写 daemon 服 务 程序 时 ， 基 本 上 都 有 这 样 的 流程 : 首先 关闭 标准 输出 
stdout、 标 准 出 错 stderr， 然 后 进行 dup 操 作 ， 将 stdout 或 stderr 重 定向 。 但 是 在 多 线程 程序 成 为 主流 以 后 ， 
由 于 close 和 dup 操 作 不 是 原子 的 ， 这 就 造成 了 在 某 些 情况 下 ， 重 定向 会 失败 。 因 此 就 引入 了 dup2 将 close 
和 dup 合 为 一 个 系统 调用 ， 以 保证 原子 性 ， 然 而 这 依然 有 问题 。 大 家 可 以 回顾 1.2.2 节 中 对 O_CLOEXEC 
的 介绍 。 在 多 线程 中 进行 fork 操 作 时 ，dup2 同 样 会 有 让 相同 的 文件 描述 符 暴 露 的 风险 ，dup3 也 就 随 之 诞 
生 了 。 这 三 个 系统 调用 看 起 来 有 些 见 余 重 复 ， 但 实际 上 它们 也 是 软件 工程 发 展 的 结果 。 从 这 个 dup 的 发 
展 过 程 来 看 ， 我 们 也 可 以 领会 到 编写 健壮 代码 的 不 易 。 正 如 前 文 所 述 ， 对 于 一 个 现代 接口 ， 一 般 都 会 
有 一 个 flag 标 志 参 数 ， 这 样 既 可 以 保证 兼容 性 ， 还 可 以 通过 引用 新 的 标志 来 改善 或 纠正 接口 的 行为 。 






































下 面 先 看 dup 的 实现 ， 如 下 所 示 : 


SYSCALL DEFINE1 (dup, unsigned int, fildes) 
{ 


int ret = -EBADF; 
/* 必须 先 得 到 文件 管理 结构 


£1i1le， 同 时 也 是 对 描述 符 


fijldes 的 检查 

BA 
struct file *file = fget raw (fildes); 
if (file) { 

















/* 得 到 一 个 未 使 用 的 文件 描述 符 





3 
ret = get unused fd(); 
if (ret >= 0) { 
/* 将 文件 描述 符 与 
fi 1e 指 针 关 联 起 来 
*/ 
fd install (ret, file); 
} 
else 
fput (file); 


} 


Eoeltuen Ket 





然后 ， 再 看 看 finstall 的 实现 ， 代 码 如 下 所 示 : 





void fd install (unsigned int fd, struct file *file) 
{ 
Struct files. struct. *files = CUrrent->files; 
struct fdtable *fdt; 
/* 对 文件 表 进 行 保护 


*/ 
spin lock(g&files->file lock); 
/* 得 到 文件 表 


本 
fdqt = files fdtable (files); 
BUG ON (fqt->fd[fd] != NULL); 
/* 让 文件 表 中 





下 d 对 应 的 指针 等 于 该 文件 关联 结构 


file */ 
rcou. assign pointer (fqt~>fqd[lfd], filée); 
spin unlock (&files->file lock); 








在 dup 中 调用 get_unused 乌 ， 只 是 得 到 一 个 未 用 的 文件 描述 符 ， 那 么 如 何 实现 在 dup 接 口中 使 用 最 小 
的 未 用 文件 描述 符 呢 ? 这 就 需要 回顾 1.4.2 节 中 总 结 过 的 Linux 文 件 描述 符 的 选择 策略 了 。 


Linux 总 是 尝试 给 用 户 最 小 的 未 用 文件 描述 符 ， 所 以 get_unused 和 得 到 的 文件 描述 符 始终 是 最 小 的 


可 用 文件 描述 符 。 





在 乌 install 中 ， 包 与 fle 的 关联 是 利用 妈 来 作为 指针 数组 的 索引 的 ， 从 而 让 对 应 的 指针 指向 fle。 对 
于 dup 来 说 ， 这 意味 着 数组 中 两 个 指针 都 指向 了 同一 个 fle。 而 file 是 进程 中 真正 的 管理 文件 的 结构 ， 文 
件 偏 移 等 信息 都 是 保存 在 fle 中 的 。 这 就 意味 着 ， 当 使 用 oldfd 进 行 读 写 操作 时 ， 无 论 是 oldfq 还 是 newfda 
的 文件 偏 移 都 会 发 生变 化 。 

















再 来 看 一 下 dup2 的 实现 ， 如 下 所 示 : 





SYSCALL DEFINE2 (dup2, unsigned int, oldfd, unsigned int, newfd) 
{ 


/* 如 果 
oldfqd 与 
newfqd 相 等 ， 这 是 一 种 特殊 的 情况 


#/ 
if (unlikely (newfd == oldfd)) { /* corner case */ 
struct files struct *files = current->files; 
int retval = oldfqd; 
/* 
检查 


O1Ldfd 的 合法 性 ， 如 果 是 合法 的 
fd， 则 直接 返回 


Oldfq 的 值 ; 


如 果 是 不 合法 的 ， 则 返回 


EBADF 
人 
rcu read lock(); 
if (!fcheck files (files, oldfd)) 
retval = -EBADF; 
rcu read unlock(); 
return retval; 
} 
/* 如 果 
oldfq 与 











newfd 不 同 ， 则 利 








SyS_qdup3 来 实现 


dup2 */ 
return sys dup3 (oldfd, newfd, 0); 
} 





再 来 查看 一 下 dup3 的 实现 代码 ， 如 下 所 示 : 





SYSCALL DEFINE3 (dup3, unsigned int, oldfd, unsigned int, newfd, int, flags) 
{ 





int err = -EBADF; 

struct file * file, *tofree; 

struct files struct * files = current->files; 
struct fdtable *fdt; 

/* 对 标志 





£1ags 进 行 检查 ， 支 持 


O_CLOEXEC */ 
if ((flags & ~O CLOEXEC) != 0) 
return -EINVAL; 
X* 济 














dup2 不 同 ， 当 


oldfqd 与 


newfd 相 同 的 时 候 ， 


dup3 返 回 错误 


大 
/ 
if (unlikely (oldfd == newfd) ) 
return -EINVAL; 
Spin lock(&files->file lock); 
/* 根据 








Dewfd 决 定 是 否 需 要 扩展 文件 表 的 大 小 


志 / 
err = expand files (files, newfd); 
/* 
检查 


Oldfqd， 如 果 是 非法 的 ， 就 直接 返回 


不 过 我 更 倾向 于 先 检查 





Oldfqd 后 扩展 文件 表 ， 如 果 是 非法 的 ， 就 不 需要 扩展 文件 表 了 


党 

. 

file = fcheck (oldfd); 

if (unlikely(!file)) 
goto Ebadf; 

if (unlikely(err < 0)) { 
if (err == -EMFILE) 

goto Ebadf; 

goto out unlock; 

















} 
err = -EBUSY; 
/* 得 到 文件 表 





*/ 
fat = files fdtable (files); 
/* 通过 


newfd 得 到 对 应 的 


file 结 构 


tofree = fdt->fd[lnewfd]; 
/* 
tofree 是 


NULL, 但 是 


newfd 已 经 分 配 的 情况 


*/ 

if (!tofree && FD ISSET(newfd, fdt->open fds)) 
goto out unlock; 

/* ”增加 

















file 的 引用 计数 





Ry 
get file(file); 
/* 将 文件 表 


newfd 对 应 的 指针 指向 


file */ 
rcu assign pointer (fdt->fd[lnewfd], file); 
/* 
将 


newfqd 加 到 打开 文件 的 位 图 中 





如 果 


newfd 已 经 是 一 个 合法 的 


于 Q， 重 复 设置 位 图 则 没有 影响 ; 


如 果 








Dewfd 没 有 打开 ， 则 必须 将 其 加 入 位 图 中 


那么 为 什么 不 对 


Dewfd 进 行 检查 呢 ? 因为 检查 比 设置 位 图 更 消耗 


EPEU 
*/ 
FD SET (newfd, fdt->open fds); 
/* 
如 果 





flags 设 置 了 





O_CLOEXEC, 则 将 











newfqd 加 到 


ClOose_on exec 位 图 ; 


如 果 没 有 设置 ， 则 清除 





ClOse_on exec 位 图 中 对 应 的 位 


Rd 
if (flags & O CLOEXEC) 
FD SET (newfd, fdt->close on exec); 














else 





FD CLR (newfd, fdt->close on exec); 
spin unlock (&files->file lock); 
/* 如 果 


七 of ree 不 为 空 ， 则 需要 关闭 


Dewfd 之 前 的 文件 


*/ 
if (tofree) 
filp close (tofree, files); 
return newfd; 
Ebadf: 
err = -EBADF; 
out unlock: 
spin unlock (gfiles->file lock); 
return err; 











1.10 文件 数据 的 同步 


为 了 提高 性 能 ， 操 作 系 统 会 对 文件 的 IO 操作 进行 缓存 处 理 。 对 于 读 操 作 ， 如 果 要 读 取 的 内 容 已 经 
存在 于 文件 缓存 中 ， 就 直接 读 取 文件 缓存 。 对 于 写 操 作 ， 会 先 将 修改 提交 到 文件 缓存 中 ， 在 合适 的 时 
机 或 者 过 一 段 时 间 后 ， 操 作 系统 才 会 将 改动 提交 到 磁盘 上 。 





Linux 提 供 了 三 个 同步 接口 : 





void Sync (void) ; 
int fsync(int fqd); 
int fdatasync (int fdq) ， 





APUE 上 说 sync 只 是 让 所 有 修改 过 的 缓存 进入 提交 队列 ， 并 不 用 等 待 这 个 工作 完成 。Linux 手 册 上 则 
表示 从 1.3.20 版 本 开始 ，Linux 就 会 一 直 等 待 ， 直 到 提交 工作 完成 。 





实际 情况 到 底 是 怎样 的 呢 ， 让 代码 告诉 我 们 真相 ， 有 具体 如 下 : 








SYSCALL DEFINE0 (sync) 
{ 


/* 唤醒 后 台 内 核 线程 ， 将 * 脏 “缓存 冲刷 到 磁盘 上 


*/ 
wakeup flusher threads (0, WB REASON SYNC); 
/* 
为 什么 要 调用 两 次 


Sync_filesystems 呢 ? 


这 是 一 种 编程 技巧 ， 第 一 次 
sync filesystems (0) ， 参 数 


0 表示 不 等 待 ， 可 以 


迅速 地 将 没有 上 锁 的 
inode 同 步 。 第 二 次 
sync_filesystems ( 工 ) 参数 


1 表示 等 待 。 


对 于 上 锁 的 


ijnode 会 等 待 到 解锁 ， 再 执行 同步 ， 这 样 可 以 提高 性 能 。 因 为 第 一 次 操作 


中 ， 上 锁 的 





inode 很 可 能 在 第 一 次 操作 结束 后 ， 就 已 经 解锁 ， 这 样 就 避免 了 等 竺 


4 

sync filesystems (0); 
sync filesystems (1); 
/* 

如 果 是 


laptop 模 式 ， 那 么 因为 此 处 刚刚 做 完 同步 ， 因 此 可 以 停 掉 后 台 同 步 定 时 器 


上 

if (unlikely(LIaptop mode)) 
laptop sync completion(); 

return 0; 





再 看 一 下 sync _filesystems->iterate_supers->sync_one sb-> sync filesystem， 代 码 如 下 : 





static int Sync filesystem(struct super block *sb, int wait) 
{ 
/* 
* This should be safe, as we require bdi backing to actually 
* write out data in the first place 
*/ 
if (sb->s bdi == &noop backing dev_ info) 
return 0; 
/* 磁盘 配额 同步 





* 
if (sb->s qcop && sb->s qcop->quota sync) 
sb->s_qcop->quota sync(sb, -1, wait); 
/* 
如 果 
Wait 为 


七 YUe， 则 一 直 等 待 直 到 所 有 的 脏 


ijnode 写 入 磁盘 


如 果 


wait 为 


false， 则 启动 脏 


ijnode 回 写 工 作 ， 但 不 必 等 待 到 结束 


4 
if (wait) 

sync inodes sb (sb); 
else 


writeback inodes sbl(sb, WB REASON SYNC); 
/* 如 果 该 文件 系统 定义 了 自己 的 同步 操作 ， 则 执行 该 操作 


妆 / 
if (sb->s op->sync fs) 

sb->s_op->sync fs(sb, wait); 

/* 调 




















lock 设 备 的 


flush 操 作 ， 真 正 地 将 数据 写 到 设备 上 


4 
} 


return _ sync blockdev (sb->s bdev, wait); 





从 sync 的 代码 实现 上 看 ，Linux 的 sync 是 阻塞 调用 ， 这 里 与 APUE 的 说 明 是 不 一 样 的 。 





下 面 来 看 看 人 ync 与 faatasync， 全 ync 只 同步 乌 指 定 的 文件 ， 并 且 直 到 同步 完成 才 返回 。fqatasync 与 
fsync 类 似 ， 但 是 其 只 同步 文件 的 实际 数据 内 容 ， 和 会 影响 后 面 数据 操作 的 元 数据 。 而 fsync 不 仅 同 步 数 
据 ， 还 会 同步 所 有 被 修改 过 的 文件 元 数据 ， 代 码 如 下 所 示 : 








SYSCALL DEFINE] (fsync, unsigned int, fd) 
{ 
return do fsync(fd, 0); 
} 
SYSCALL DEFINE] (fdatasync, unsigned int, fd) 
{ 


return do fsync(fd, 1); 








事实 上 ， 真 正 进 行 工 作 的 是 do_fsync， 代 码 如 下 所 示 : 





static int do fsync(unsigned int fd, int datasync) 
{ 

struct file *file; 

int ret = -EBADF; 

/* 得 到 


file 管 理 结构 




















BA 
file = fget (fqd); 
if (file) { 
/* 利 
Vfs 执 行 
Sync 操 作 
* 


ret = vfs fsync(file, datasync); 
fput (file); 
} 


Eeturn, Eets 





进入 vfs_fsync->vfs_fsync_range， 代 码 如 下 : 





int vfs fsync range(struct file *file, loff t start, loff t end, int datasync) 
{ 











/* 调用 有 具体 操作 系统 的 同步 操作 








if ‘(tfile=>f op || ‘file->f op->fsync) 
return -EINVAL; 
return file->f op->fsync(file, start, end, datasync); 











真正 执行 同步 操作 的 fsync 是 由 具体 的 文件 系统 的 操作 函数 科 e_operations 决 定 的 。 下 面 选择 一 个 常 


用 的 文件 系统 同步 函数 generic_file fync， 代 码 如 下 。 





int. generio file fsync (struot file *filey off t starty To0ff t, :end, 
int datasync) 
{ 


struct inode *inode = file->f mapping->host; 
int err; 
int ret; 

/* 同步 该 文件 缓存 中 处 于 





Start 到 


eng 范 围 内 的 脏 页 


大 
err = filemap write and wait range (inode->i mapping, start, end) ， 
if (err) 
return err; 
mutex lock(&inode->i mutex); 
/* 同步 该 本 





ijnode 对 应 的 缓存 


流 
ret = sync mapping buffers (inode->i mapping); 
/* inode 状 态 没 有 变化 ， 无 需 同步 ， 可 以 直接 返回 


#7/ 
if (!(inode->i state & I DIRTY)) 
goto out; 
/* 如 果 是 


fdatasync 则 仅 做 数据 同步 ， 并 且 若 该 


inode 没 有 影响 任何 数据 方面 操作 的 变化 比如 文件 长 度 )， 则 可 以 直接 返回 


机 
if (datasync && !(inode->i state & I DIRTY DATASYNC)) 
goto out; 
/* 
同步 


inode 的 元 数据 


7 
err = sync inode metadata (inode, 1); 
if£ (ret == .0) 

ret = err; 


mutex unlock(&inode->i mutex); 
return ret; 





从 上 面 的 代码 可 以 看 出 ，faatasync 的 性 能 会 优 于 fync。 在 不 需要 同步 所 有 元 数据 的 情况 下 ， 选 择 
faatasync 会 得 到 更 好 的 性 能 。 只 有 在 inode 被 设置 了 I DIRTY DATASYNC 标 志 时 ，faatasync 才 需要 同步 








inode 的 元 数据 。 那 么 inode 何 时 会 被 设置 L DIRTY DATASYNC 这 个 标志 呢 ? 比如 使 用 文件 截断 truncate 
或 fruncate 时 ;， 通 过 在 源码 中 搜索 I DIRTY DATASYNC 或 mark inode _dirty 时 也 会 给 inode 设 置 该 标志 
位 。 而 调用 mark inode dirty 的 地 方 就 太 多 了 ， 这 里 就 不 列举 了 。 

















© 注意 sync、fsync 和 fdatasync 只 能 保证 Linux 内 核对 文件 的 缓冲 被 冲刷 了 ， 并 不 能 保证 数据 
被 真正 写 到 磁盘 上 ， 因 为 磁盘 也 有 自己 的 缓存 。 








1.11 文件 的 元 数据 


1.10 节 中 我 们 提 到 了 文件 元 数据 ， 那 么 什么 是 文件 的 元 数据 呢 ? 其 包括 文件 的 访问 权限 、 上 次 访问 
的 时 间 戴 、 所 有 者 、 所 有 组 、 文 件 大 小 等 信息 。 





1.11.1 获取 文件 的 元 数据 


Linux 环 境 提 供 了 三 个 获取 文件 信息 的 API: 





#include <sys/types.h> 

#include <sys/stat.h> 

#include <unistd.h> 

int stat(const char *path, struct stat *buf); 
int fstat(int fd, struct stat *buf); 

int lstat(const char *path, struct stat *buf); 








三 个 函数 都 可 用 于 得 到 文件 的 基本 信息 ， 区 别 在 于 stat 得 到 路 径 path 所 指定 的 文件 基本 信息 ，fstat 


得 到 文件 描述 符 人 包 指 定 文 件 的 基本 信息 ， 而 lstat 与 stat 则 基本 相同 ， 








得 到 的 是 链接 文件 自己 本 身 的 基本 信息 而 不 是 其 指向 文件 的 信息 。 


所 得 到 的 文件 基本 信息 的 结果 struct stat 的 结构 如 下 : 


只 有 当 path 是 一 个 链接 文件 时 ，1lstat 





struct stat { 





dev t st_ dev; /* ID of device containing file */ 
ino 七 st ino; /* inode number */ 

mode 七 st mode; /* protection */ 

nlink t st nlink; /* number of hard links */ 

uid t st uid; /* user ID of owner */ 

gid 七 st gid; /* group ID of owner */ 

devt st rdev; /* device ID (if special file) */ 

信 E 下 七 st size; /* total size, in bytes */ 

blksize t st blksize; /* blocksize for file system I/O */ 
blkcnt t st blocks; /* number of 512B blocks allocated */ 
time t st atime; /* time of last access */ 

time t st mtime;  /* time of last modification */ 
time t st ctime; /* time of last status change */ 





Linux 的 man 手 册 对 stat 的 各 个 变量 做 了 注释 ， 明 确 指 出 了 
st mode， 其 不 仅仅 是 注释 所 说 的 “protection"， 即 权限 管理 ， 





件 还 是 目录 。 


个 变量 的 意义 
同时 也 用 于 表示 文件 类 型 ， 


一 需要 说 明 的 是 


比如 是 普通 文 


1.11.2 内核 如 何 维护 文件 的 元 数据 





要 搞 清 楚 Linux 如 何 维护 文件 的 元 数据 ， 就 需要 追踪 stat 的 实现 ， 有 具体 代码 如 下 : 








SYSCALL DEFINE2(stat, const char _user *, filename, 
struct old kernel stat user *, statbuf) 
{ 














struct kstat stat 
int error; 
/* Vfs_stat 用 于 读 取 文 件 元 数据 至 




















stat */ 
error = vfs stat (filename, &stat); 
if (error) 
return error; 
/* 这 里 仅 是 从 内 核 的 元 数据 结构 














Stat 复 制 到 用 户 层 的 数据 结构 











statkbuf 中 





*/ 
return cp old stat(&stat, statbuf); 





进入 vfs_stat->vfs_fstatat->vfs_getattrtr， 代 码 如 下 : 





int vfs getattr(struct vfsmount *mnt, struct dentry *dentry, struct kstat *stat) 
{ 

struct inode *inode = dentry->d inode; 

int retval; 

/* 对 获取 


inode 属 性 操作 进行 安全 性 检查 


大 
/ 
retval = security inode getattr (mnt, dentry); 
if (retval) 
return retval; 
/* ”如果 该 文件 系统 定义 了 这 个 


inode 的 自 定义 操作 函数 ， 就 执行 它 


*/ 
if (inode->i op->getattr) 
return inode->i op->getattr (mnt, dentry, stat); 
/* 如 果 文 件 系统 没有 定义 














inode 的 操作 函数 ， 则 执行 通用 的 函数 








类 


generic fillattr(inode, stat); 
return 0; 


} 





不 失 一 般 性 ， 也 可 以 通过 查看 generic fillattr 来 进一步 了 解 ， 代 码 如 下 : 


void generic fillattr(struct inode *inode, struct kstat *stat) 
{ 

tat->dev = inode->i sb->s dev; 

tat->ino = inode->i ino; | 

tat->mode = inode->1i mode; 

tat->nlink = inode->i nlink; 

tat->uid = inode->i uid; 

tat->gid = inode->i gid; 

tat->rdev = inode->i rdev; 

tat->size = i size read(inode); 
tat->atime inode->i atime; 

tat->mtime inode->i mtime; 

tat->ctime inode->i ctime; 
tat->blksize = (1 << inode->i blkbits); 
tat->blocks = inode->i blocks; 








[0 


从 这 里 可 以 看 出 ， 所 有 的 文件 元 数据 均 保 存在 inode 中 ， 而 inode 是 Linux 也 是 所 有 类 Unix 文 件 系 统 中 
的 一 个 概念 。 这 样 的 文件 系统 一 般 将 存储 区 域 分 为 两 类 ， 一 类 是 保存 文件 对 象 的 元 信息 数据 ， 即 inode 
表 ; 另 一 类 是 真正 保存 文件 数据 内 容 的 块 ， 所 有 inode 完 全 由 文件 系统 来 维护 。 但 是 Linux 也 可 以 挂 载 非 
类 Unix 的 文件 系统 ， 这 些 文件 系统 本 吴 没 有 inode 的 概念 ， 怎 么 办 ? Linux 为 了 让 VFS 有 统一 的 处 理 流 程 
和 方法 ， 就 必须 要 求 那些 没有 inode 概 念 的 文件 系统 ， 根 据 自己 系统 的 特点 一 一 如 何 维护 文件 元 数据 ， 
生成 “虚拟 的 ”inode 以 供 Linux 内 核 使 用 。 



































1.11.3 权限 位 解析 








在 Linux 环 境 中 ， 文 件 常见 的 权限 位 有 r、w 和 x， 分 别 表 示 可 读 、 可 写 和 可 执行 。 
不 常用 的 标志 位 。 


1.SUID 权 限 位 





下 面 重点 解析 三 个 


当 文 件 设置 SUID 权 限 位 时 ， 就 意味 着 无 论 是 谁 执行 这 个 文件 ， 都 会 拥有 该 文件 所 有 者 的 权限 。 














passwd 命 令 正 是 利用 这 个 特性 ， 来 允许 普通 用 户 修改 自己 的 密码 ， 因 为 只 有 root 用 户 才 有 修改 密码 文件 
的 权限 。 当 普通 用 户 执行 passwd 命 令 时 ， 就 具有 了 root 权 限 ， 从 而 可 以 修改 自己 的 密码 。 











以 修改 文件 属性 的 权限 检查 代码 为 例 ，inode_change ok 用 于 检查 该 进程 是 否 有 权限 修改 inode 节 点 





的 属性 即 文件 属性 ， 示 例 代码 如 下 : 











int inode change ok(const struct inode *inode, struct iattr *attr) 


unsigned int ia valid = attr->ia valid; 


/* Make sure a caller can chown. */ 
/* 只 有 在 


uid 和 


Suid 都 不 符合 条 件 的 情况 下 ， 才 会 返回 权限 不 足 的 错误 


7/ 





if ((ia valid & ATTR UID) && 
(current fsuid() != inode->i uiqd || 
attr->ia uid != inode->i uid) && !capable (CAP CHOWN)) 
return -EPERM; 
} 
2.SGID 权 限 位 


SGID 与 SUID 权 限 位 类 似 ， 当 设置 该 权限 位 时 ， 就 意味 着 无 论 是 谁 执行 该 文件 ， 都 会 拥有 该 文件 所 


有 者 所 在 组 的 权限 。 





3.Stricky 位 














Stricky 位 只 有 配置 在 目录 上 才 有 意义 。 当 目录 配置 上 sticky 位 时 ， 其 效果 是 即使 所 有 的 用 户 都 拥有 
写 权 限 和 执行 权限 ， 该 目录 下 的 文件 也 只 能 被 root 或 文件 所 有 者 删除 。 


下 面 来 看 看 内 核 的 实现 : 





static int may delete(struct inode *dir,struct dentry *victim,int isdir) 


if (check sticky(dir, victim->d inode)|| 
IS APPEND (victim->d inode) | | 
IS IMMUTABLE (victim->d inode) || 
~ IS SWAPFILE (victim->d inode)) 
return -EPERM; 

















在 删除 文件 前 ， 内 核 要 调用 may_delete 来 判断 该 文件 是 否 可 以 被 删除 。 在 这 个 函数 中 ， 内 核 通 过 调 
用 check sticky 来 检查 文件 的 sticky 标 志 位 ， 其 代码 如 下 : 





static inline int check sticky(struct inode *dir, struct inode *inode) 
{ 
/* 得 到 当前 文件 访问 权限 的 


uid */ 
uid 七 fsuid = current fsuid(); 
/* 判断 上 级 目录 是 否 设 置 了 


Sticky 标 志 位 


*/ 
if (!(dir->i mode & S_ISVTX) ) 
return 0; 
/* 检查 名 称 空间 
*/ 


if (current user ns() != inode userns (inode)) 
goto other userns; 
/* 检查 当前 文件 的 














Ui 是否 与 当前 用 户 的 








uid 相同 


*#/ 
if (inode->i uid == fsuid) 
return 0; 
/* 检查 文件 所 处 目录 的 











Uid 是 否 与 当前 用 户 的 


























uigd 相 同 
*/ 
if (dir->i uid == fsuid) 
return 0; 
/* 该 文件 不 属于 当前 用 户 
人 


other userns: 
return !ns_capable (inode userns (inode), CAP FOWNER); 
} 











当 文 件 所 处 的 目录 设置 了 sticky 位 ， 即 使 用 户 拥有 了 对 应 的 权限 ， 只 要 不 是 目录 或 文件 的 拥有 者 ， 
就 无 法 删除 该 文件 除非 该 用 户 拥有 CAP_FOWNER 能 力 ( 读 者 可 以 通过 man 7 capabilities 来 进一步 了 
解 Linux 中 的 capabilities。 一 般 只 有 root 用 户 才 有 这 样 的 能 力 ) 。 





四 
说 明 ”大 家 可 以 使 用 chmod 来 设置 文件 或 目录 的 权限 。 


1.12 ”文件 截断 


1.12.1 truncate 与 ftruncate 的 简单 介绍 


Linux 提 供 了 两 个 截断 文件 的 API: 





#include <unistd.h> 

#include <sys/types.h> 

int truncate (Const char *path, off t length); 
int ftruncate(int fd, off 七 length); 





两 者 之 间 的 唯一 区 别 在 于 ，truncate 和 截断 的 是 路 径 path 指 定 的 文件 ，ftruncate 和 截断 的 是 乌 引 用 的 文 
件 。 


~ 


截断 "给 人 的 感觉 是 将 文件 变 短 ， 即 将 文件 大 小 缩短 至 length 长 度 。 实 际 上 ，length 可 以 大 于 文件 本 
身 的 大 小 ， 这 时 文件 长 度 将 变 为 length 的 大 小 ， 扩 充 的 内 容 均 被 填充 为 0。 需 要 注意 的 是 ， 尺 管 fruncate 
使 用 的 是 文件 描述 符 ， 但 是 其 并 不 会 更 新 当前 文件 的 偏 移 。 





1.12.2 文件 截断 的 内 核实 现 


先 来 看 看 truncate 的 内 核实 现 ， 代 码 如 下 : 














SYSCALL DEFINFE2 (truncate const char _user *, path, long, length) 
{ 


} 





return do sys truncate (path, length); 





进入 do_sys_truncate， 代 码 如 下 : 





static long do sys truncate(const char user *pathname, loff t length) 
{ 
struct path path; 
struct inode *inode; 
int error; 
error = -EINVAL; 
/* 长 度 不 能 为 负数 





* 
if (lengthn < 0) 
goto out; 
/* 得 到 路 径 结构 


4 
error = user _ path (pathname, &path); 
if (error) 


goto out; 
inode = path.dentry->d inode; 
error = -EISDIR; 





/* 目录 不 能 被 截断 


大 
/ 
if (S_ISDIR(inode->i mode)) 
goto dput and out; 
error = -EINVAL; 
/* 不 是 普通 文件 不 能 被 截断 





所 
if (!S ISREG(inode->i mode)) 
goto dput and out; 
/* 尝试 获得 文件 系统 的 写 权限 





大 
/ 
error = mnt want write (path.mnt); 
if (error) | 
goto dput and out; 
/* 检查 是 否 有 文件 写 权 限 


上 





rror = inode permission (inode, MAY WRITE) ， 
if (error) 
goto mnt drop write and out; 
error = -EPERM; 
/* 文件 设置 了 追加 属性 ， 则 不 能 被 截断 

















*/ 
if (IS_ APPEND (inode)) 
goto mnt drop write and out; 
/* 得 到 








Inoqe 的 写 权限 





rror = get write access (inode); 
if (error) | 

goto mnt drop write and out; 
/* 查看 是 否 与 文件 





lease 锁 相 冲 突 


*/ 
rror = break lease(inode, O WRONLY); 
if (error) 
goto put write and out;/ 





* 检查 是 否 与 文件 锁 相 冲突 


sy 


error = locks verify truncate(inode, NULL, length); 
if (lerror) 加 

error = security path truncate (&path) ， 
/* 如 果 没 有 错误 ， 则 进行 真正 的 截断 


类 1 
if (!erzor) 
error = do truncate (path.dentry, length, 0, NULL); 
put write and out: 
put write access (inode); 
mnt drop write and out: 
mnt drop write (path.mnt); 
dput and out: 
path Put (&path); 
Gut: 


} 





return error; 





再 进入 do_truncate， 代 码 如 下 : 





int do truncate (Struct dentry *dentry, loff t length, unsigned int time attrs, 
struct file *filp) 
{ 


int ret; 
struct iattr newattrs; 
if (Length < 0) 
return -EINVAL; 
/* 设置 要 改变 的 属性 ， 对 于 截断 来 说 ， 最 重要 的 是 文件 长 度 








大 
A 
newattrs.ia size = length; 
newattrs.ia valid = ATTR SIZE | time attrs; 
if (filp) 全 一 一 
newattrs.ia file = filp; 
newattrs.ia valid |= ATTR FILE; 





} 
/* 
SUid 权 限 一 定 会 被 去 掉 


同时 设置 


Sgid 和 
XGIPH, 
Sgid 权 限 也 会 被 去 掉 
7 
ret = should remove suidl(dentry); 
if (ret) 
newattrs.ia valid |= ret | ATTR FORCE; 
/* 修改 
ijnode 属 性 
4 


mutex lock(&dentry->d inode->i mutex); 
ret = notify change (dentry, &newattrs); 
mutex unlock (&dentry->d inode->i mutex); 
a = anh A = 





接 下 来 看 fstrucate 的 实现 ， 代 码 如 下 : 








SYSCALL DEFINE2 (ftruncate, unsigned int, fd, unsigned long, length) 
{ 
/* 真正 的 工作 函数 





qo_sys_fLtruncate */ 
long ret = do sys ftruncate(fd, length, 1); 
/* avoid REGPARM breakage on x86: */ 
asmlinkage protect(2, ret, fd, length); 
tn ety 








最 后 ， 进 入 do_sys_ftruncate， 代 码 如 下 : 





static long do sys ftruncate(unsigned int fd, loff t length, int small) 
{ 

struct inode * inode; 

struct dentry *dentry; 

struct file * file; 

int error; 

error = -EINVAL; 

/* 长 度 检查 





雪人 
if (Length < 0) 
goto out 7; 
error = -EBADF; 
/* 从 文件 描述 符 得 到 





file 指 针 


7 


file = fget (fqd); 
if (!file) 

goto out; 
/* 如 果 文件 是 以 














O 〇 LARGEFILE 选 项 打开 的 ， 则 将 标志 


small 置 为 


0 即 假 


A 


A/ 





if (file->f flags & O LARGEFILE) 
small = 0; 

dentry = file->f path.dentry; 

inode = dentry->d inode; 

error = -EINVAL; 

/* 如 果 文 件 不 是 普通 文件 或 文件 不 是 写 打开 ， 则 报错 




















if (!S ISREG(inode->i mode) || !(file->f mode & FMODE WRITE) ) 
goto out putf; 
error = -EINVAL; /* Cannot ftruncate over 2^31 bytes without large file support */ 


/* 如 果 文 件 不 是 以 


O 〇 LARGEFILE 打 开 的 话 ， 长 度 就 不 能 超过 





MAX NON LFS */ 


wy 


六 


发 太 


if (small && length > MAX NON LFS) 
goto out putf; 

error = -EPERM; 

/* 如 果 是 追加 模式 打开 的 ， 也 不 能 进行 截断 





if (IS APPEND (inode)) 
goto out putf; 
/* 检查 是 否 有 锁 冲突 








error = locks verify truncate(inode, file, length); 
if (lerror) 加 

error = security path truncate (&file->f path); 
if (!lerror) { 时 加 

/* 执行 截断 操作 -前 文 已 经 分 析 过 


error = do truncate (dentry, length, ATTR MTIME|ATTR CTIME, file);} 


out putf: 


SOU: 


} 


fput (file); 


return error; 





1.12.3 ”为 什么 需要 文件 截断 








文件 截断 时 允许 指定 比 原 有 文件 长 度 更 长 的 值 ， 但 更 常见 的 是 指定 的 长 度 比 原 有 长 度 短 ， 这 主要 
用 于 防止 文件 内 容 混杂 了 旧 内 容 的 情况 。 下 面 以 常见 的 daemon 程 序 为 例 〈 演 示 一 个 文件 因 不 截断 而 引 
发 的 pug) ， 这 种 程序 往往 要 将 自己 的 pid 写 入 一 个 pid 文 件 中 。 当 daemon 程 序 启 动 的 时 候 ， 最 好 是 将 旧 
的 pid 文 件 截断 ， 然 后 写 入 新 的 pid， 不 然 pid 文 件 中 可 能 会 保存 错误 的 pid。 














假设 当前 的 test.pid 文 件 的 内 容 是 上 一 次 的 pid。 





[fgao@fgao chapterl]#cat test.pid 
123456 








下 面 的 程序 是 将 新 的 pid 一 一 6789 写 入 test.pid 中 。 





#include <sys/types.h> 

#include <sys/stat.h> 

#include <fcntl.h> 

#include <unistd.h> 

int main (voidgd) 

{ 
int fd = open("test.pid", O WRONLY); 
write(fd, "6789", sizeof ("6789")-1); 
close (fd); 
return 0; 





程序 执行 完毕 ， 让 我 们 看 看 testpid 的 内 容 : 





[fgao@fgao chapterl]#cat test.pid 
678956 








这 显然 不 是 我 们 所 期 望 的 结果 。 为 了 解决 这 个 问题 ， 我 们 可 以 在 打开 文件 的 同时 ， 指 定 O_TRUNC 


标志 。 





int fd = open("test.pidq"，O WRONLY | O TRUNC); 





或 者 使 用 本 节 介 绍 的 截断 API， 代 码 如 下 : 





truncate ("test.pid", 0); 
int fd = open("test.pid", O WRONLY); 





或 者 用 如 下 代码 : 





int fd = open("test.pid", O WRONLY); 
ftruncate (fd, 0); 














这 样 ， 就 能 保证 旧 内 容 不 会 与 最 新 写 入 的 内 容 混 杂 在 一 起 。 


也 许 有 朋友 会 提出 ， 在 上 面 的 例子 中 写 入 “6789” 时 ， 这 样 写 就 不 会 有 问题 了 : 








write(fd, "6789", sizeof ("6789")); 








然而 结果 仍然 是 错 的 ， 其 结果 为 : 


[fgao@ubuntu chapterl]#cat test.pid 
67896 





这 里 列举 的 例子 用 的 是 文本 文件 ， 如 果 写 入 的 是 一 个 二 进 制 文件 ， 当 不 使 用 文件 截断 而 导致 新 旧 
数据 混杂 在 一 起 时 ， 定 位 错误 将 更 加 困难 。 所 以 ， 在 我 们 的 日 常 编码 中 ， 在 写 入 文件 ， 如 果 并 不 需要 
日 数据 ， 那 么 在 打开 文件 时 就 要 强制 截断 文件 ， 来 提高 代码 的 健壮 性 。 
































二 











第 2 章 ”标准 IO 库 





前 面 的 章节 介绍 的 是 Linux 的 系统 调用 。 本 章 将 从 标准 IO 库 开 始 讲解 Linux 环 境 编程 中 不 可 或 缺 的 C 
。 在 学 习 和 分 析 标 准 IO 库 的 同时 ， 与 Linux 的 IO 系统 调用 进行 比较 ， 可 以 加 深 对 两 者 的 认识 和 理解 。 





2 


1 stdin、stdout 和 stderr 








当 Linux 新 建 一 个 进程 时 ， 会 自动 创建 3 个 文件 描述 符 0、1 和 2， 分 别 对 应 标准 输入 、 标 准 输 出 和 错 


误 输出 。C 库 中 与 文件 描述 符 对 应 的 是 文件 指针 ， 与 文件 描述 符 0、1 和 2 类 似 ， 我 们 可 以 直接 使 用 文件 
指针 stdin、stdout 和 和 stderr。 那 么 这 是 否 意味 着 stdin、stdout 和 stderr 是 “自动 打开 ”的 文件 指针 呢 ? 


查看 C 库 头 文 件 stdio.h 中 的 源码 : 





typedef struct _IO_FILE FILE; 

/* Standard streams. */ 

extern struct IO FILE *stdin; /* Standard input stream. */ 
extern struct _IO FILE *stdout; /* Standard output stream. */ 
extern struct IO FILE *stderr; /* Standard error output stream. */ 
#ifdef STDC 

/* C89/C99 say they're macros. Make them happy. */ 

#define stdin stdin 

#define stdout stdout 

#define stderr stderr 

#endif 


从 上 面 的 源码 可 以 看 出 ，stdin、stdout 和 和 stderr 确 实 是 文件 指针 。 而 C 标 准 要 求 stdin、stdout 和 stderr 是 





宏 定义 ， 所 以 在 C 库 的 代码 中 又 定义 了 同名 宏 。 


那么 stdin、stdout 和 和 stderr 又 是 如 何 定 义 的 呢 ? 定 义 代码 如 下 : 





和 
的 


IO FILE *stdin = (FILE *) & IO 2 1 stdin ; 


IO FILE *stdout = (FILE *) & IO 2 1 stdout ; 
IQ. FILE *stderr = (FILE *) & 10 2 1 stderr » 








继续 查看 IO 2 1 stdin 等 的 定义 ， 代 码 如 下 : 








DEF STDFILE( IO 2 1 stdin , 0, 0, _IO NO WRITES); 


DEF STDFILE( IO 2 1 stdout , 1, & IO 2 1 stdin , IO NO READS); 
DEF STDFILE( IO 2 1 stderr , 2, & IO 2 1 stdout , IO NO READS+ IO UNBUFFERED); 














DEF_STDFILE 是 一 个 宏 定义 ， 用 于 初始 化 C 库 中 的 FILE 结 构 。 这 里 IJO 2 1 stdin、_IO 2 1 stdout 





_IO_2_1_stderr 这 三 个 FILE 结 构 分 别 用 于 文件 描述 符 0、1 和 2 的 初始 化 ， 这 样 C 库 的 文件 指针 就 与 系统 














文件 描述 符 互 相关 联 起 来 了 。 大 家 注意 最 后 的 标志 位 ，stdin 是 不 可 写 的 ，stdout 是 不 可 读 的 ， 而 stderr 











不 仅 不 可 读 ， 且 没有 缓存 。 


太 


人 让 





通过 上 面 的 分 析 ， 可 以 得 到 一 个 结论 : stdin、stdout 和 stderr 都 是 FILE 类 型 的 文件 指针 ， 是 由 C 库 静 
定义 的 ， 直 接 与 文件 描述 符 0、1 和 2 相关 联 ， 所 以 应 用 程序 可 以 直接 使 用 它们 。 





























2.2 JJO 缓 存 引出 的 趣 题 





C 库 的 IO 接 口 对 文件 1O 进 行 了 封装 ， 为 了 提高 性 能 ， 其 引入 了 缓存 机 制 ， 共 有 三 种 缓存 机 制 : 全 
缓存 、 行 缓存 及 无 缓存 。 





` 全 缓存 一 般 用 于 访问 真正 的 磁盘 文件 。C 库 会 为 文件 访问 申请 一 块 内 存 ， 只 有 当 文件 内 容 将 缓存 
填 满 或 执行 冲刷 函数 fush 时 ，C 库 才 会 将 缓存 内 容 写 入 内 核 中 。 





行 缓存 一 般 用 于 访问 终端 。 当 遇 到 一 个 换行 符 时 ， 就 会 引发 真正 的 IO 操作 。 需 要 注意 的 是 ，C 库 
的 行 缓存 也 是 固定 大 小 的 。 因 此 ， 当 缓存 已 满 ， 即 使 没有 换行 符 时 也 会 引发 TO 操 作 。 





无 缓存 ， 顾 名 思 义 ，C 库 没有 进行 任何 的 缓存 。 任 何 C 库 的 IO 调 用 都 会 引发 实际 的 IO 操作 。 





C 库 提供 了 接口 ， 用 于 修改 默认 的 缓存 行为 ， 相 关 代 码 如 下 : 





#include <stdio.h> 

void setbuf (FILE *stream, char *buf); 

void setbuffer (FILE *stream, char *buf, size t size); 

void setlinebuf (FILE *stream); 

int setvbuf (FILE *stream, char *buf, int mode, size t size); 











下 面 看 一 个 跟 C 库 缓存 相关 的 趣 题 。 





#include <stdio.h> 
#include <stdlib.h> 
#include <unistd.h> 
int main (void) 


printtE ("HSLLIG ) 

if (0 == fork()) { 
Deirnttf ("oniLldN\n)y 
return 0; 


} 
printf ("parent\n"); 
return 0; 





其 输出 结果 是 什么 ? 正确 的 结果 是 : 





Hello parent 
Hello child 





或 者 : 





Hello child 
Hello parent 





之 所 以 是 这 样 的 结果 ， 就 是 因为 背后 的 行 缓存 。 执 行 printf〈"Hello"〉 时 ， 因 为 printf 是 向 标准 输出 
打印 的 ， 因 此 使 用 的 是 行 缓存 。 字 符 串 Hello 没 有 换行 符 ， 所 以 并 没有 真正 的 VO 输出 。 当 执行 fork 时 ， 
子 进 程 会 完全 复制 父 进程 的 内 存 空间 ， 因 此 字符 串 Hello 也 存在 于 子 进程 的 行 缓存 中 。 故 而 最 后 的 输出 








进程 还 是 子 进程 都 有 Hello 字 符 串 。 





2.3 ”fopen 和 open 标 志 位 对 比 


























C 库 的 fopen 用 于 打开 文件 ， 其 内 部 实现 必然 要 使 用 open 系 统 调 用 。 那 么 fopen 的 各 个 标志 位 又 对 应 open 的 哪些 标志 位 呢 ? 请 看 表 2-1。 














表 2-1 fopen 标 志 位 和 open 标 志 位 对 应 表 


O_WRONLYIO_CREATI 以 写 方式 打开 文件 ; 当 文件 存在 时 ， 将 其 大 小 截断 为 0 ; 当 文 
O_TRUNC 件 不 存在 时 ， 创建 该 文件 


We O_RDWRIO_CREATIO_ | 以 读 写 方式 打开 文件 ; 当 文 件 存在 时 ， 将 其 大 小 截断 为 0 ; 当 
TRUNC 文件 不 存在 时 ,创建 该 文件 


WwW 


( 续 ) 
fopen 标志 位 open 标志 位 用 途 
O_ WRONLY|O APPEND 
a Jo_ GREAT 0- 以 追加 写 的 方式 打开 文件 ， 当 文件 不 存在 时 ， 创 建 该 文件 
at RO_APPENDI9 | 以 筷 加 读 写 的 方式 打开 文件 ， 当 文件 不 存在 时 ， 创 建 该 文件 


CREAT 




















表 2-1 是 fopen 常 用 的 标志 位 ， 实 际 上 fopen 还 有 更 多 的 标志 位 ， 这 也 是 很 多 书籍 没有 涉及 的 ， 具 体 见 表 2-2。 




















表 2-2 更 多 的 fopen 和 open 标 志 位 对 应 


fopen 标志 位 open 标志 位 用 途 
, 该 文件 流 在 1/O 操作 时 不 能 被 取消 

当 进 程 执行 exee 时 ， 该 文件 流 会 自动 关闭 

该 文件 流通 过 mmap 来 打开 或 访问 ， 只 支持 读 取 操作 

one 在 创建 文件 时 ， 如 果 文 件 已 经 存在 ，fopen 则 会 返回 失败 而 不 

是 打开 这 个 文件 


表示 打开 的 文件 是 二 进 制 流 而 不 是 文本 流 。 该 标志 目前 在 
Linux 中 是 无 用 的 



































下 面 进入 glibc 的 源码 ， 查 看 函数 IJO_new_file fopen 来 验证 上 面 的 结论 。 





Id 了 EL * 
_IO new file fopen (fp, filename, mode, is32not64) 
”IO FILE *fp; 
Const char *filename; 
const char *mode; 
int is32not64; 


int oflags = 0, omode; 

int read write; 

int oprot = 0666; 

Tn 

IO FILE *result; 

#ifdef LIBC 

const char *cs; 

const char *last recognized; 
#endif 加 

if ( IO file is _ open (fp)) 

return 0; 
switch (*mode) 
{ 


Case 'r': 
omode = O RDONLY; 
read write = _IO NO WRITES; 
break; 

Case Ww': 
omode = O WRONLY; 
oflags = O CREAT|O TRUNC; 
read write = _IO NO READS; 


break; 
SS AT 


omode = O WRONLY; 
oflags = O_CREAT|O APPEND; 
read write = 10 NO READS| IO IS APPENDING; 


break; 
default: 


Set errno (EINVAL); 


return NULL; 
} 
#ifdef _LIBC 


last recognized = mode; 


#endif 


be A a Sf 


. 
Switch (*++mode) 
{ 


case "NO" 
break; 
Hades HF 


omode = O_RDWR; 


read write &= _IO IS APPENDING; 


#ifdef LIBC 


last recognized = mode; 


#endif 
continue; 
Co 


oflags |= O_EXCL; 


#ifdef LIBC 
last recognized 
#endif 加 
continue; 
ase "D's 
#ifdef LIBC 
last recognized 
#endif 加 
continue; 
case 'm': 


= mode; 


= mode; 


fp-> flags2 |= _IO_ FLAGS2 MMAP; 


continue; 
Se 


fp-> flags2 |= _IO_ FLAGS2 NOTCANCEL; 


continue; 
vas “S$ 
#ifdef O CLOEXEC 


oflags |= O CLOEXEC; 


#endif 


fp-> flags2 |= _IO FLAGS2 CLOEXEC; 


continue; 
default: 
/* Ignore. */ 
continue; 
} 
break; 


} 


result = I0 file open 


is32not64) 


过 


(fp, filename, omodeloflags, oprot, read write, 








上 面 的 源 代码 非常 











人 


上 团 


包 


单 ， 很 容易 至 














E 解 。 每 个 mode 都 是 switch 语 句 的 一 个 case，oflags 就 是 要 传 给 open 的 标志 位 ， 这 就 验 订 


E 了 前 文 的 结论 。 


2.4 fdopen 与 fileno 




















Linux 提 供 了 文件 描述 符 ， 而 C 库 又 提供 了 文件 流 。 在 平时 的 工作 中 ， 有 时 候 需 要 在 两 者 之 间 进 行 
切换 ， 因 此 C 库 提供 了 两 个 API: 











#include <stdio.h> 
FILE *fdopen(int fd, const char *mode); 
int fileno (FILE *stream); 








fopen 用 于 从 文件 描述 符 包 生成 一 个 文件 流 FILE， 而 fileno 则 用 于 从 文件 流 FILE 得 到 对 应 的 文件 描述 








查看 fdopen 的 实现 ， 其 基本 工作 是 创建 一 个 新 的 文件 流 FILE， 并 建立 文件 流 FILE 与 描述 符 的 对 应 关 
系 。 我 们 以 fleno 的 简单 实现 ， 来 了 解 文件 流 FILE 与 文件 描述 符 乌 的 关系 。 一 一 因为 该 函数 代码 较 长 ， 
在 此 就 不 罗列 C 库 的 代码 了 。 代 码 如 下 : 

















int filend ( 10 FILE* fp) 
{ 
CHECK FILE (fp, EOF); 
if (!(fp-> flags & IO IS FILEBUF) || _ IO fileno (fp) < 0) 
{ 
__ Set errno (EBADF); 
return -1; 
} 
return IO fileno (fp); 


} 
#define IO fileno(FP) ((FP)-> fileno) 


从 fileno 的 实现 基本 上 就 可 以 得 知 文件 流 与 文件 描述 符 的 对 应 关系 。 文 件 流 FILE 保 存 了 文件 描述 符 
的 值 。 当 从 文件 流转 换 到 文件 描述 符 时 ， 可 以 直接 通过 当前 FILE 保 存 的 值 _fileno 得 到 包 。 而 从 文件 描 
符 转 换 到 文件 流 时 ，C 库 返回 的 都 是 一 个 重新 申请 的 文件 流 FILE， 且 这 个 FILE 的 _fileno 保 存 了 文件 描述 


AD 


符 。 


























因此 无 论 是 fdopen 还 是 fleno， 关 闭 文件 时 ， 都 要 使 用 felose 来 关闭 文件 ， 而 不 是 用 close。 因 为 只 有 
采用 此 方式 ，felose 作 为 C 库 函数 ， 才 会 释放 文件 流 FILE 占 用 的 内 存 。 





2.5 同时 读 写 的 痛苦 


前 面 介 绍 过 内 核 的 文件 描述 符 实 现 。 在 内 核 中 ， 每 一 个 文件 描述 符 人 都 对 应 了 一 个 文件 管理 结构 
struct file 一 一 用 于 维护 该 文件 描述 符 的 信息 ， 如 偏 移 量 等 。 在 第 1 章 对 read 和 write 的 源码 分 析 中 ， 可 以 
发 现 每 一 次 系统 调用 的 read 和 write 成 功 返 回 后 ， 文 件 的 偏 移 量 都 会 被 更 新 。 














因此 ， 如 果 程 序 对 同一 个 文件 描述 符 进 行 读 写 操作 的 话 ， 肯 定 会 得 到 非 期 望 的 结果 ， 示 例 代码 如 








#include <stdio.h> 
#include <stdlib.h> 
#include <string.h> 
int main (void) 
{ 
char buf[20]; 
int ret; 
FILE *fp = fopen("./tmp.txt", "w+"); 
i (lfp) + 
printf ("Fail to open file\n") 
return -1; 
} 
ret = fwrite ("123", sizeof ("123"),; 1, fp); 
printf(" we write sq member\n", ret); 
memset (buf, 0, sizeof (buf)); 
ret = fread(buf, 1, 1, fp); 
printf (" 'We read %s, ret is %d\n", buf, ret);，; 
fwritel(" oe sizeof ("456"), 1, fp); 
fclose (fp 
return oo 





上 面 的 代码 中 ， 利 用 fopen 的 读 写 模式 打开 了 一 个 文件 流 ， 先 写 入 一 个 字符 串 “123”， 然 后 读 取 一 个 


字 节 ， 再 写 入 一 个 字符 串 “456”。 








大 家 想 想 输出 结果 会 是 什么 呢 ? fread 读 取 的 字符 又 会 是 什么 昵 ? 是 否 为 "1" 呢 ? 请 看 下 面 的 结果 : 


[fgao@ubuntu chapter2]#./a.out 
we write 1 member 
We read , ret is 0 


为 什么 fread 什 么 都 没有 读 取 到 ， 返 回 值 是 0 呢 ? 这 是 因为 上 面 的 代码 中 ，fwrite 和 fread 操 作 的 是 同 
一 个 文件 指针 和 名， 也 就 是 对 应 的 是 同一 个 文件 描述 符 。 第 一 次 fwrite 后 ， 在 tmp.txt 中 写 入 了 字符 
串 “123”， 同 时 文件 偏 移 为 3， 也 就 是 到 了 文件 尾 。 进 行 fead 操 作 时 ， 既 然 操作 的 是 同一 个 文件 描述 
， 自 然 会 共享 同一 个 文件 仿 移 ， 那 么 ， 从 文件 尾 自然 读 取 不 到 任何 数据 。 



































2.6 ”ferror 的 返回 值 


ferror 用 于 告诉 用 户 C 库 的 文件 流 FILE 是 否 有 错误 发 生 。 当 有 错误 发 生 时 ，ferror 返 回 非 零 值 ， 反 之 
则 返回 0。 那 么 ferror 是 否 会 返回 不 同 的 错误 呢 ? 让 我 们 来 看 看 ferror 的 源码 。 








weak alias (_ IO ferror, ferror) 
半 和 六 _IO ferror (fp) 

_IO FILE* fp; 
{ 


int result; 
/* 检查 文件 流 的 有 效 性 ， 失 败 则 返回 


EOF */ 
CHECK FILE (fp, EOF); 
IO flockfile (fp); 
result = IO ferror unlocked (fp) 
JO funlockfile (fp); 
return result; 




















进入 _IO ferror unlocked， 代 人 码 如 下 : 





#define IO ferror unlocked( fp) ((( fp)-> flags & IO ERR SEEN) != 0) 
#define IO ERR SEEN 0x20 




















从 源码 上 可 以 看 出 ferror 有 两 个 返回 值 : 
` 当 文件 流 FILE*fp 非 法 时 ， 返 回 EOF (-1) 。 
` 当 文件 流 FILE*fp 前 面 的 操作 发 生 错 误 时 ， 返 回 1。 


并 且 由 于 文件 流 的 错误 只 是 使 用 一 个 标志 位 IO_ERR _SEEN 来 表示 的 ， 因 此 ferror 的 返回 值 就 不 可 
能 针对 不 同 的 错误 返回 不 同 的 值 了 。 








2.7 ”clearerr 的 用 途 


2.6 节 中 的 ferror 用 于 检测 文件 流 是 否 有 错误 发 生 ， 而 clearerr 用 于 清除 文件 流 的 文件 结束 位 和 错误 


位 。 


查看 clearerr 的 实现 ， 代 码 如 下 : 





#define clearerr unlocked (x) clearerr (x) 
void 
clearerr unlocked (fp) 
FILE *fp; 
{ 


CHECK FILE (fp, /*nothing*/); 
_IO clearerr (fp); 
} 
#define IO clearerr(FP) ((FP)-> flags &= ~( IO ERR SEEN| IO EOF SEEN)) 























可 见 ，clearerr 可 以 清除 文件 流 中 的 文件 结尾 标志 和 错误 标志 。 





但 是 清除 错误 标志 又 有 什么 用 处 呢 ? 按照 某 些 资料 上 的 描述 ， 当 文件 流 读 到 文件 尾 时 ， 文 件 流 会 
被 设置 上 EOF 标 志 。 如 果 不 使 用 clearerr 清 除 EOF 标 志 ， 即 使 有 新 的 数据 ， 也 无 法 读 取 成 功 。 





让 我 们 写 个 程序 来 验证 一 下 : 








#include <stdlib.h> 
#include <stdio.h> 
int main (void) 


{ 





FILE *fp = fopen("./tmp.txt", "“r"); 
if (!fp) { 
PFintf("Fail to fopen\n"); 
return -1; 


} 
while (1) { 
int c = getc (fp); 
if (feof (fp)) { 
printf("reach feof\n"); 
} 
} 


return 0; 





为 了 满足 前 面 所 说 的 测试 情况 ， 我 们 使 用 gdb 来 控制 程序 ， 代 码 如 下 : 





31 int c = getc (fp); 

(gdb) 

33 if (feof (fp)) { 

(gdb) n 

34 printf("reach feof\n"); 





现在 ， 文 件 流 外 已 经 读 到 了 文件 尾 ， 被 设置 上 了 EOF 标 志 。 接 下 来 向 tmp.txt 奶 加 一 个 字母 aa"。 





[fgao@fgao chapter3]#echo "a" >> tmp.txt 





继续 gdb，getc 仍 然 可 以 继续 读 取 ， 并 获得 新 数据 。 





31 int c = getc (fp); 
(gdb) 

33 if (feof (fp)) { 
(gdb) pc 

$1 = 97 

(gdb) p /cc 

$2 = 97 'a' 








34 printf ("reach feof\n"); 





我 们 可 以 发 现 虽 然 此 时 文件 流 多 仍然 是 被 设置 了 EOF 标 志 ， 但 是 依然 能 够 成 功 读 取 数据 。 这 与 某 些 
资料 的 摘 述 不 符 ， 这 就 应 对 了 那 句 老 话 “ 尽 信 书 不 如 无 书 ”， 对 于 一 些 资 料 的 结论 ， 不 要 完全 相信 ， 而 
是 要 通过 自己 的 实践 来 验证 。 











下 面 回 到 glibe 的 源码 ， 查 看 _IO_getce， 从 代码 中 了 解 为 什么 是 这 样 的 结果 。 





int 
IO getc (fp) 
FILE *fp; 


{ 
int result; 
/* 检查 


fp */ 
CHECK FILE (fp, EOF); 
_IO acquire lock (fp); 
result = _IO getc unlocked (fp); 
_IO release lock (fp); 
return result; 

















} 
/* 只 有 定义 了 


IO_DEBUG 





CHECK_FILE 才 会 检查 











_IO file flags 标 志 ， 





当 其 不 为 


0 时 ， 则 返回 错误 值 。 对 于 


fgetc 即 为 


EOF 

*/ 

#ifdef IO DEBUG 

# define CHECK FILE(FILE, RET) \ 


也 
if ((FILE) == NULL) { MAYBE SET EINVAL; return RET; } \ 




















else { COERCE FILE(FILE); \ 
if (((FILE)-> IO file flags & IO MAGIC MASK) != I0O MAGIC) \ 
{ MAYBE SET EINVAL; return RET; }} | nt o> 
#else 
# define CHECK FILE (FILE, RET) COERCE FILE (FILE) 
#endif 加 








从 glibc 的 源码 中 可 以 发 现 ， 文 件 流 FILE 的 错误 标志 位 只 有 在 打开 IO_DEBUG 的 情况 下 才 会 对 后 面 的 
VO 调用 产生 影响 :在 有 错误 标志 位 的 时 候 ， 后 面 的 VO 调用 都 会 直接 返回 EOF。 而 一 般 情况 
下 ，IO_DEBUG 这 个 宏 是 没有 定义 的 。 


























2.8 小 心 fgetc 和 getc 





fgetc 和 getc 是 两 个 定义 得 很 不 友好 的 函数 ， 其 函 


函数 名 中 的 getc 很 容易 让 使 用 者 误 以 为 
字符 。 实 际 上 两 个 函数 的 接口 定义 如 下 : 


其 返回 值 是 char 








#include <stdio.h> 
int fgetc(FILE *stream); 
int getc (FILE *stream); 





两 者 的 返回 值 都 是 int 类 型 。 为 什么 要 用 int 类 


型 作为 返回 值 呢 ? 因为 当 文 件 流 读 到 文件 尾 时 ， 需 要 
返回 EOF 值 。C99 标 准 中 规定 了 EOF 为 一 个 int 类 型 的 负数 常量 ， 并 没有 规定 具体 的 值 


被 定义 为 -1 且 char 为 有 符号 


























。 在 glibc 中 ，EOF 








数 。 但 是 不 能 排除 某 些 实现 将 EOF 定 义 为 其 他 负 值 





， 甚 至 可 能 因为 不 遵守 
C99 标 准 ，EOF 的 值 有 可 能 超过 char 的 表示 范围 。 因 此 ， 为 了 代码 的 健壮 性 和 可 移植 性 ， 在 使 用 fgetc 和 
getc 时 ， 应 使 用 int 类 型 的 变量 保存 其 返回 值 。 








2.9 注意 ffead 和 fwrite 的 返回 值 


fread 和 和 fwrite 的 声明 代码 如 下 : 





#include <stdio.h> 
size t freadl(void *ptr, size t size, size t nmemb, FILE *stream); 
Size 七 fwrite (Const void *ptr, size t size, Size t nmemb, FILE *stream); 














这 两 个 函数 原型 很 容易 让 人 产生 误解 。 当 看 到 返回 值 类 型 为 size t 时 ， 人 们 很 有 可 能 理解 为 fead 和 
fwrite 会 返回 成 功 读 取 或 写 入 的 字 节 数 ， 然 而 实际 上 其 返回 的 是 成 功 读 取 或 写 入 的 个 数 ， 即 有 多 少 个 
size 大 小 的 对 象 被 成 功 读 取 或 写 入 了 。 而 参数 nmemb 则 用 于 指示 ffead 或 fwrite 要 执行 的 对 象 个 数 。 

















看 看 下 面 的 示例 代码 : 





#include <stdlib.h> 

#include <stdio.h> 

#include <string.h> 

int main (void) 

{ 
const char str[] = "123456789"; 
FILE *fp = fopen("tmp.txt", “w"); 
size t size = fwrite(str, strlen(str), 1, fp); 
printf("size is Sd\n", size); 
fclose (fp); 
return 0; 








这 段 代码 的 输出 为 : 





size is 1 





结果 并 不 是 写 入 的 字符 串 长 度 9， 而 是 返回 写 入 的 对 象 个 数 1。 其 原因 是 参数 ptr 指 示 的 是 要 写 入 对 
象 的 地 址 ，size 为 每 个 对 象 的 字 节 数 ，nmemb 为 有 多 少 个 要 写 入 的 对 象 。 


将 上 面 的 代码 稍微 变换 一 下 ， 将 fwrite 的 语句 改 为 : 





size t size = fwrite(str, 1, strlen(str), fp); 








这 时 程序 的 输出 就 变 为 : 





size is 9 





其 原因 在 于 ， 参 数 size 表 示 每 个 对 象 的 字 节 数 是 1 字 节 ，nmemb 表 示 要 写 入 9 个 对 象 ， 因 此 返回 值 就 
变 为 9 了 。 


2.10 创建 | 





备 时 文件 








在 项 目 中 经 常会 需要 生成 临时 文件 ， 用 于 保存 临时 数据 ， 创 建 管道 文件 、Unix 域 socket 等 。 为 了 不 
与 已 有 的 文件 同名 ， 或 者 避免 与 其 他 临时 文件 相 冲 突 ， 有 些 朋友 可 能 会 选择 利用 进程 dg、 时 间 截 等 来 生 
成 临时 文件 名 。 其 实 ，C 库 已 经 提供 了 生成 临时 文件 的 接口 。 下 面 对 生成 临时 文件 的 各 种 方法 进行 分 析 
对 比 。 先 来 看 看 tmpnam 方 式 ， 代 码 如 下 : 




















#include <stdio.h> 
char *tmpnam(char *s); 








tmpnam 会 返回 一 个 目前 系统 不 存在 的 临时 文件 名 。 当 $ 为 NULL 时 ， 返 回 的 文件 名 保存 在 一 个 静态 
的 缓存 中 ， 因 此 再 次 调用 tmpnam 时 ， 新 生成 的 文件 名 会 覆盖 上 一 次 的 结果 。 当 s 不 为 NULL 时 ， 生 成 的 
临时 文件 名 会 保存 在 s 中 ， 因 此 要 求 至 少 要 有 C 库 规定 的 L_tmpnam 大 小 。C 库 同时 还 规定 tmpnam 产 生 的 
临时 文件 的 路 径 以 P_ tmpdir 开 头 一 一 glibc 中 P tmpdir 定 义 为 /tmp。 














从 上 面 的 描述 中 可 以 清楚 地 发 现 tmpnam 的 缺点 : 











. 当 $ 为 NULL 时 ，tmpnam 不 是 线程 安全 的 。 


tmpnam 生 成 的 临时 文件 名 ， 必 须 位 于 固定 的 路 径 下 (/tmp)。 





使 用 tmpnam 创 建 临时 文件 不 是 一 个 原子 行为 ， 需 要 先生 成 临时 文件 名 ， 然 后 调用 其 他 IO 函数 创建 
文件 。 这 有 可 能 会 导致 在 创建 文件 时 ， 该 文件 已 经 存在 。 











再 来 看 看 tmpfile 方 式 : 


#include <stdio.h> 
FILE *tmpfile (void); 








tmpfile 返 回 一 个 以 读 写 模式 打开 的 、 唯 一 的 临时 文件 流 指 针 。 当 文件 指针 关闭 或 程序 正常 结束 时 ， 
该 临时 文件 会 被 自动 删除 。 





tmpfile 直 接 返 回 临时 的 文件 流 指针 一 一 这 个 自然 避免 了 tmpnam 中 潜在 的 线程 安全 问题 ， 同 时 还 避 
免 了 将 生成 文件 名 和 创建 文件 分 为 两 个 步骤 来 执行 的 行为 。 那 么 tmpfile 是 否 真 的 实现 了 原子 地 创建 临时 
文件 ? 让 我 们 看 一 下 tmpfile 的 实现 ， 代 码 如 下 : 











FILE * 
tmpfile (void) 


char buf [FILENAME MAX]; 

int > 加 

FILE *f; 

if ( path search (buf, FILENAME MAX, NULL, “tmpf", 0)) 
return NULL; 


int flags = 0; 
#ifdef FLAGS 
flags = FLAGS; 


#endif 
fd= gen tempname (buf, 0, flags, _ GT FILE); 
if (fd < 0) 


return NULL; 
/* Note that this relies on the UNIX semantics that 
a file is not really removed until it is closed. */ 


(void) _ unlink (buf); 

if ((f = fdopen (fd, "w+b")) == NULL) 
close (fd); 

return f; 








乍 一 看 ，tmpfile 是 通过 ”path search 先 产生 临时 文件 名 ， 然 后 再 创建 该 文件 ， 最 后 通过 文件 句柄 生 
成 文件 流 指针 。 这 样 的 过 程 看 上 去 好 像 并 不 是 原子 的 。 下 面 ， 让 我 们 深入 到 ”gen_tempname 中 一 探究 


Be = ok 
网 o 








case _ GT FILE: 
fd= open (tmpl, 
(flags & ~O ACCMODE) 
| O RDWR | O CREAT | O EXCL, S_ IRUSR | S_ IWUSR); 
break; 

















在 创建 临时 文件 时 ，C 库 使 用 了 open 函 数 的 O CREAT 和 QO_EXCL 标 志 组 合 ， 这 点 保证 了 文件 的 原子 
性 创建 ， 从 而 使 mpfile 创 建 临 时 文件 的 行为 是 原子 的 。 但 tmpfile 也 有 一 个 缺点 ， 与 tmpnam 相 同 ， 这 个 临 
时 文件 只 能 生成 在 固定 的 路 径 下 WwWtmp) ， 并 且 其 有 可 能 因为 文件 名 称 冲 突 而 失败 返回 NULL。 









































么 ， 有 没有 可 以 给 临时 文件 指定 目录 的 方法 呢 ? 下 面 请 看 mkstemp， 代 码 如 下 : 











#include <stdlib.h> 
int mkstemp (char *template); 





mkstemp 会 根据 template 创 建 并 打开 一 个 独一无二 的 临时 文件 。template 的 最 后 6 个 字符 必须 
是 “XXXXXX”。glibc 库 会 生成 一 个 独一无二 的 后 级 来 蔡 换 “XXXXXX”， 因 此 要 求 template 必 须 是 可 以 修 
改 的 。 








mkstemp 执 行 成 功 后 会 返回 创建 的 临时 文件 的 文件 描述 符 ， 失 败 时 则 返回 -1。 下 面 看 一 下 mkstemp 的 
实现 。 





int #mkstemp (template) 
char *template; 
{ 
return _gen tempname (template, 0, 0, _ GT FILE) ， 
} 


进入 gen tempname 后 : 


int # gen tempname (char *tmpl, int suffixlen, int flags, int kind) 


int len; 

char *XXXXXXx; 

static uint64 t value; 
uint64 t random time Lt 
unsigned int count; 


int fd = -1; 

int save errno = errno; 

struct stat64 st; 
#define ATTEMPTS MIN (62 * 62 * 62) 

/* The number of times to attempt to generate a temporary file. To 

conform to POSIX, this must be no smaller than TMP MAX. */ 

#if ATTEMPTS MIN < TMP MAX 

unsigned int attempts = TMP MAX; 
#else 

unsigned int attempts = ATTEMPTS MIN; 
#endif 

/* 检查 











template 的 合法 性 ， 检 查 长 度 及 结尾 的 


XXXXXX 字 符 
6 
len = Strlen (tmpl); 
if (len < 6 + suffixlen || memcmp (&tmpl[len - 6 - suffixlen], "XXXXXX", 6)) 


{ 
__ set errno (EINVAL); 
return -1; 


} 


/* 得 到 结尾 


XXXXXX 起 始 位 置 


*] 
XXXXXX = &tmpl[llen - 6 - suffixlen]; 
/* 得 到 \ 随 机 “数据 


4 
#ifdef RANDOM BITS 
RANDOM BITS (random time bits); 

















#else 
#if HAVE GETTIMEOFDAY || LIBC 
{ 
struct timeval tyv; 
__ gettimeofday (&tv, NULL); 
random time bits = ((uint64 t) tv.tv usec << 16) ^ 
tv.tv sec; 
} 
#else 
random time bits = time (NULL); 
#endif 本 加 
#endif 
/* 根据 上 面 的 伪 随 机 数 和 进程 





pid 生成 





value */ 
value += random time bits 
/* 
根据 


入 


getpiqd () 





Value 得 到 唯一 的 临时 文件 名 ， 如 有 重复 则 加 上 





7777 继 续 。 


最 多 重复 





attempts 次 。 


汇 4 


for (count = 0; count < attempts; 


{ 


uint64 t v = value; 


7 
letters 是 


26 个 英文 大 小 写 加 上 


1 0 个 阿拉 伯 数 字 ， 为 








62 个 大 小 的 字符 数组 。 因 此 使 




















62 作 为 除数 ， 


以 得 到 随机 字符 。 












































本/ 
XXXXXX[0] = letters 多 
V /= 62; 
XXXXXX[1] = letters 多 
V /= 62; 
XXXXXX [2] = letters 多 
Vv /= 62; 
XXXXXX[3] = letters 多 
Vv /= 62; 
XXXXXX[4] = letters 多 
V /= 62; 
XXXXXX[5] = letters 多 
Switch (kind) 
{ case _ GT FILE: 
/* 这 是 
mkstemp 的 情况 ， 利 
O_CREAT | O ”EXCL 创 建 唯一 文件 
* 
fd= open (tmpl, 


(flags & ~O ACC 


| O RDWR | O CREAT | O EXCL, S IRUSR | S IWUSR); 


break; 
} 
if (fd >= 0) 
{ 





62]3 
62]; 
621. 
62]; 


621]3 





621]3 


ODE) 


/* 成 功 创建 了 文件 ， 恢 复原 来 的 


enO， 并 返回 创建 的 文件 描述 符 


Value += 7777, ++count) 





fd #/ 
__Set errno (save errno); 
return fq; 
} 
else if (errno != EEXIST) { 


/* 如 失败 的 原因 不 是 因为 文件 已 经 存在 的 时 候 ， 则 直接 返回 。 





*/ 
return -1; 
} 
/* 如 果 是 其 他 原因 ， 则 会 重新 生成 新 的 文件 名 ， 并 再 次 尝试 重建 
*/ 
} 
/* 将 
errno 设 置 为 





EEXIST， 即 文件 已 经 存在 


1 
_ Set errno (EEXIST); 
return -1; 


} 





综 上 所 述 ， 在 需要 使 用 临时 文件 时 ， 不 推荐 使 用 tmpnam， 而 要 月 








tmpfile 和 mkstemp。 前 者 的 局 限 在 


于 不 能 指定 路 径 ， 并 且 在 文件 名 称 冲突 时 会 返回 失败 。 后 者 可 以 由 调用 者 来 指定 路 径 ， 并 且 在 文件 名 


称 冲突 时 ， 会 自动 重新 生成 并 重 试 。 








除了 上 面 介绍 的 几 种 方法 ，Linux 环 境 还 提供 了 这 些 接口 的 一 些 变 种 : tempnam、mkostemp、 
mkstemps 等 ， 分 别 对 其 原始 形态 进行 了 扩展 ， 详 细 区 别 可 以 直接 查看 Linux 手 册 。 





第 3 革 ”进程 环境 


进程 是 操作 系统 运行 程序 的 一 个 实例 ， 也 是 操作 系统 分 配 资源 的 单位 。 在 Linux 环 境 中 ， 每 个 进程 
都 有 独立 的 进程 空间 ， 以 便 对 不 同 的 进程 进行 隔离 ， 使 之 不 会 互相 影响 。 深 入 理解 Linux 下 的 进程 环 
境 ， 可 以 帮助 我 们 写 出 更 健壮 的 代码 。 














3.1 main 是 C 程 序 的 开始 吗 





在 编写 C 程 序 的 时 候 ， 都 是 从 main 函 数 开 始 ， 然 而 main 函 数 真 的 是 C 程 序 的 入 口 吗 ? 让 我 们 来 看 看 
下 面 的 程序 : 





#include <stdlip.h> 
#inclugde <stdio.h> 
static void attripbute  ((constructor)) before main (void) 


printf ("Before main...\n"); 


int main (void) 

{ 
printf ("Main!\n"); 
return 0; 


} 





其 执行 结果 为 : 





Before main... 
Main! 








从 运行 结果 中 ， 可 以 发 现 before main 是 在 进入 main 函 数 之 前 被 调用 的 ， 这 点 对 于 C 语 言 的 初学 者 来 
说 似乎 有 点 难以 接受 。 究 竟 是 谁 调用 的 before_main 呢 ? 怎么 还 没有 进入 main 就 可 以 有 代码 被 执行 呢 ? 








回忆 一 下 第 0 章 所 讲 的 基础 知识 ， 在 编译 的 过 程 中 可 以 使 用 -v 来 详细 地 显示 编译 的 过 程 。 在 此 ， 截 
取 gcc 4 1 _main stackc-v 输 出 的 一 部 分 结果 ， 如 下 所 示 : 








/usr/libexec/gcc/i686-redhat-linux/4.6.3/collect2 --build-id --no-add-needed 
--eh-frame-hdr -m elf i386 --hash-style=gnu -dynamic-linker /lib/1ld-linux. 
so.2 /usr/lib/gcc/i686-redhat-linux/4.6.3/../../../crtl.o /usr/lib/gcc/i686- 
redhat-linux/4.6.3/../../../crti.o /usr/lib/gcc/i686-redhat-linux/4.6.3/ 
crtbegin.o -L/usr/lib/gcc/i686-redhat-linux/4.6.3 -L/usr/lib/gcc/i686- 
redhat-linux/4.6.3/../../.. /tmp/cc3tzF7V.o -lgcc --as-needed -lgcc s --no- 
as-needed -lc -lgcc --as-needed -lgcc s --no-as-needed /usr/lib/gcc/i686- 
redhat-linux/4.6.3/crtend.o /usr/lib/gcc/i686-redhat-linux/4.6.3/../../../ 
crtn.o 











可 以 看 到 ， 在 链接 生成 最 后 的 可 执行 文件 时 ， 有 大 量 的 C 库 二 进 制 文件 参与 进来 ， 如 crtl.o、crti.o 
等 。 可 见 最 终 的 可 执行 文件 ， 除 了 我 们 编写 的 这 个 简单 的 C 代 码 以 外 ， 还 有 大 量 的 C 库 文件 参与 了 链 
接 ， 并 包含 在 最 终 的 可 执行 文件 中 。 这 个 “组 装 ” 的 过 程 ， 是 由 链接 器 1d 的 链接 脚本 来 决定 的 。 在 没有 指 
定 链接 脚本 的 情况 下 ， 会 使 用 1d 的 默认 脚本 ， 可 以 通过 1d-verbose 来 查看 ， 下 面 截取 了 对 我 们 有 用 的 部 


分 输出 : 




















/* Script for -z combreloc: combine and sort reloc sections */ 
OUTPUT FORMAT ("elf32-i386", "elf32-i386", 

"elf32-i386") 

OUTPUT ARCH (i386) 

ENTRY (_start) 














这 里 定义 了 输出 的 文件 格式 、 目 标 机 器 的 类 型 ， 以 及 重要 的 信息 和 程序 的 入 口 ENTRY (_start) 。 








.Ctors 


{ 


/* gcc uses crtbegin.o to find the start of 
the constructors, so we make sure it is 
first. Because this is a wildcard, it 
doesn't matter if the user does not 
actually link against crtbegin.o; the 
Jinker won't look for a file to match a 
wildcard. The wildcard also means that it 
doesn't matter which directory crtbegin.o 
二 

KEEP (*crtbegin.o(.ctors)) 

KEEP (*crtbegin?.o(.ctors)) 

/* We don't want to include the .ctor section from 
the crtend.o file until after the sorted ctors. 
The .ctor section from the crtend file contains the 
end of ctors marker and it must be last */ 

KEEP (*(EXCLUDE FILE (*crtend.o *crtend?.o ) .ctors)) 

KEEP (*(SORT(.ctors.*))) 

KEEP (*(.ctors)) 








这 里 定义 了 .ctors section， 而 我 们 的 例子 中 before_main 函 数 使 用 的 gcc 扩 展 属性 





_ attribute 〈《 《constructor) ) 就 是 将 函数 对 应 的 指令 归属 于 .ctors section 中 。 

















下 面 我 们 来 退 调 一 下 Linux 可 执行 程序 完整 的 启动 过 程 。 前 面 的 链接 脚本 明确 了 入 口 为 start。 在 32 


位 的 x86 平 台中 ，_start 位 于 sysdeps/i386/start.S 中 。 


xext 
.globl _start 
type start,@function 


start.: 


/* Clear the frame pointer. The ABI suggests this be done, to mark 
the outermost frame obviously. */ 

xOorl %Sebp, Sebp 

/* Extract the arguments as encoded on the stack and set up 
the arguments for ‘main': argc, argv. envp will be determined 
later in libc start main. */ 


popl %esi /* Pop the argument count. */ 
movl %Sesp, %ecx /* argv starts just at the current stack top.*/ 


/* Before pushing the arguments align the stack to a 16-byte 

(SSE needs 16-byte alignment) boundary to avoid penalties from 
misaligned accesses. Thanks to Edward Seidl <seidl@janed.com> 
for pointing this out. */ 

andl $0Oxfffffff0, Sesp 

pushl Seax /* Push garbage because we allocate 

28 more bytes. */ 

/* Provide the highest stack address to the user code (for stacks 


which grow downwards). */ 
pushl sesp 
pushl %edx /* Push address of the shared library 


termination function. */ 

/* Push address of our own entry points to .fini and .init. */ 
pushl $ libc csu fini 

pushl $ libc csu init 

pushl gSecx /* Push second argument: argv. */ 

pushl %esi /* Push first argument: argc. */ 

pushl $BP SYM (main) 

/* Call the user's main function, and exit with its value. 

But let the libc call main. BA 

call BP SYM ( libc start main) 











上 面 列 出 的 虽然 是 汇编 代码 ， 但 是 每 一 行 都 有 清楚 的 注释 ， 这 段 代码 主要 是 为 程序 的 运行 创建 好 














运行 环境 ， 其 中 需要 注意 的 是 ，_libc_csu fini 和 libc_csu init 都 被 作为 参数 传 给 了 _ libe_start_main。 
从 这 两 个 函数 的 名 字 上 可 以 推测 它们 是 用 来 处 理 退 出 和 初始 化 阶段 的 函数 ， 那 么 .ctors section 中 的 函数 


很 可 能 








就 是 由 _1libc_csu init 来 调用 的 。 











我 们 先 来 关注 _libc_csu init 是 在 何 时 被 调用 的 ， 然 后 再 分 析 其 实现 。 上 面 的 汇编 代码 将 这 两 个 函 





数 作为 参数 传递 给 了 _libc_start_ main， 然 后 又 调用 了 generic_start main 函数 。 这 个 函数 初始 化 了 C 库 所 








需要 的 环境 ， 如 环境 变量 、 函 数 栈 、 多 线程 环境 等 ， 最 后 调用 main 函 数 一 一 进入 普通 应 用 程序 的 真正 
入 口 。 而 在 此 之 前 ， 以 下 代码 先 被 执行 : 





/* Register the destructor of the program, if any. */ 
下 
cxa atexit ((void (*) (void *)) fini, NULL, NULL); 
主 下 ”生生 萎 》 
(*init) (argc, argv, _ environ MAIN AUXVEC PARAM); 





init 即 为 ”libe_csu init， 上 面 的 代码 保证 了 libe_csu init 在 main 之 前 被 调用 。 那 么 .ctors 的 函数 又 是 
如 何 被 _libc_csu init 调 用 的 呢 ? 篇 幅 所 限 ， 在 此 我 们 就 不 罗列 代码 ， 只 给 出 其 调用 流程 : 


libc_csu init-> initt> libec global ctors。 














void 

_ libc global ctors (void) 

{/* Call constructor functions. */ 
run hooks ( CTOR LIST ); 





static inline void 
run hooks (void (*const list[]) (void) ) 
{ 
while (*++1list) 
(LS 7 式 让 沪 
} 


static void (*const _CTOR LIST [1]) (void) 
_ attribute _((used, section (".ctors"))) 
= { veid (*) {void)) =1- }» 





CTOR_LIST_ 是 一 个 函数 指针 数组 ， 数 组 的 大 小 为 1。 该 数组 使 用 gce 的 扩展 属性 ， 使 
CTOR_LIST_ 位 于 .ctors section 中 。 因 此 ， 在 上 面 的 代码 中 ，_libe_global_ctors 将 ”CTOR _LIST_ 传 
递 给 了 run_ hooks， 实 际 上 就 是 将 .ctors section 的 起 始 地 址 传递 给 J 了 run hooks。 而 _CTOR_LIST_ 位 
于 .ctors 的 第 一 个 位 置 ， 其 本 身 并 不 是 一 个 真正 的 .ctors 属 性 函数 ， 因 此 run hooks 的 while 〈*#*++list) 先 执 
行 自 增 操作 ， 即 跳 过 了 _CTOR LIST_。 












































可 以 通过 反 汇编 查 看 二 进 制 的 可 执行 程序 来 验证 





080483e4 <before main>: 


80483e4: 55 push sebp 

80483e5 : 89 e5 mov sesp sebp 

80483e7 : 83 ec 18 Sub $0x18, Sesp 
80483ea: c7 04 24 e0 84 04 08 movl $0x80484e0, (Sesp) 
80483f£1: e8 22 ff ff ff call 8048318 <puts@plt> 
80483f6 : &9 leave 

80483f7 : &3 ret 





可 以 看 到 ， 函 数 before_main 的 地 址 为 0x080483e4。 然 后 使 用 objdump 来 查看 .ctors section: 





objdump -s -j .ctors a.out 
a.out: file format elf32-i386 
Contents of section .ctors: 
8049f08 ffffffff e4830408 00000000 


可 以 看 到 ，.ctors section 的 第 一 个 元 素 即 上 文中 的 _CTOR._LIST _， 第 二 个 元 素 为 before_main 
由 于 x86 是 小 端 CPU， 因 此 0xe4830408 实 际 上 表示 的 地 址 值 为 0x080483e4。 

















需要 注意 的 是 ， 在 新 版 本 的 gcc 中 ，.ctors 属 性 的 函数 并 不 会 位 于 .ctors section 中 ， 而 是 被 gcc 合 并 到 
了 .init array section 中 。 下 面 来 看 一 下 这 种 情况 下 的 objdump 输 出 : 





[fgao@fgao chapter3]#objdump -s -]j .ctors a.out 
a.out: file format elf32-i386 
Contents of section .ctors: 

8049600 ffffffff 00000000 


可 以 看 到 ， 在 .ctors section 中 ， 没 有 任何 有 效 的 .ctors 函 数 ， 然 后 我 们 来 看 看 .init_array section: 


[fgao@fgao chapter3]#objdump -s -j .init array a.out 
a.out: file format elf32-i386 
Contents of section .init array: 

80495fc b4830408 ss 





保存 在 .init array section 中 的 函数 调用 机 制 与 之 前 分 析 的 .ctors section 机 制 类 似 ， 在 此 就 不 再 重复 
了 。 感 兴趣 的 朋友 可 以 自行 分 析 。 





说 明 ”与 constructor 属 性 对 应 的 ， 还 有 descontructor 属 性 。 拥 有 descontructor 属 性 的 函数 ， 会 
在 main 结 束 之 后 被 调用 。 














3.2 “ 活 雷 锋 ”exit 




















在 刚刚 学 习 C 语 言 的 时 候 ， 我 们 就 被 告知 分 配 内 存 以 后 ， 如 果 不 使 用 free 来 释放 内 存 ， 就 会 造成 内 存 的 泄漏 。 同 样 ， 打 开 文 件 以 后 ， 如 果 忘 记 close 也 会 造成 资源 























的 泄漏 。 那 么 ， 在 进程 退出 以 后 ， 这 些 资源 是 否 真 的 泄漏 了 呢 ? 






























































首先 ， 我 们 来 分 析 C 库 的 退出 函数 exit， 代 码 如 下 : 














可 


























当 进 程 正常 退出 时 ， 会 调用 C 库 的 exit， 而 当 进 程 崩溃 或 被 kill 掉 时 ，C 库 的 exit 则 不 会 被 调用 ， 只 会 执行 内 核 退出 进程 的 操作 。 














void 
exit (int status) 
{ 
_run exit handlers (status, & exit funcs, true); 


上 



































C 库 的 exit3 





于 



































来 执行 所 有 注册 的 退出 函数 ， 比 如 使 用 atexit 或 on_exit 注 册 的 函数 。 执 行 完 注 册 的 退出 函数 后 ，_run_exit_ handlers 会 调用 _exit， 代 码 如 下 : 





void 

_exit (status) 
int status; 

{ 


while (1) 
{ 
#ifdef _NR exit group 
INLINE SYSCALL (exit group, 1, status); 
#endif 
INLINE SYSCALL (exit, 1, status); 
#ifdef ABORT INSTRUCTION 
ABORT INSTRUCTION; 
#endif 
} 





















































不 仅仅 是 用 于 退 4 





LL 
lk 
如 

洁 



































下 面 来 看 看 系统 调用 exit_group 的 实现 : 


上 面 的 代码 很 简单 ， 当 平台 有 exit_group 时 ， 就 调用 exit_group， 否 则 就 调用 exit。 从 Linux 内 核 2.5.35 版 本 以 后 ， 为 了 支持 线程 ， 就 有 了 exit_group。 这 个 系统 调 
程 ， 还 会 让 所 有 线程 组 的 线程 全 部 退出 


[a 
Do 















































SYSCALL DEFINE] (exit group, int, error code) 
{ 
/* do_group _ exit 做 真正 的 工作 


守 
do group exit((error code & 0xff) << 8); 
/* NOTREACHED */ 
return 0; 


} 

NORET_ TYPE void 

do group exit (int exit code) 

{ 
struct signal struct *sig = current->signal; 
BUG ON (exit code & 0x80); /* core dumps don't get here */ 
/* 检查 该 线程 组 是 否 正在 退出 ， 如 果 条 件 为 真 ， 则 不 需要 设置 线程 组 退出 的 条 


件 ， 直 接 执行 本 线程 
task 退 出 流程 
do_exit 即 可 


Ry 
if (signal group exit (sig)) 
exit code = sig->group exit code; 
else if (!thread group empty(current)) { /* 线程 组 不 为 空 


*/struct sighand struct *const sighand = current->sighand; 
spin lock irq(&sighand->siglock); 
/* 标准 的 双重 条 件 检查 机 制 。 因 为 第 一 次 检查 


signal group_ exit 时 为 假 ， 但 是 男 外 一 个 线程 


已 经 拿 到 锁 ， 并 设置 了 状态 。 当 拿 到 锁 的 时 候 ， 需 要 再 次 检查 


* 
if (signal group exit(sig)) { 
/* Another thread got here before we took the lock. 
exit code = sig->group exit code; 
} 
else { 
/* 设置 线程 组 的 退出 值 和 退出 状态 
*/ 


Sig->group exit code = exit code; 


sig->flags = SIGNAL GROUP EXIT; 
/* 使 用 


SIGKILL"* 干 掉 “ 线 程 组 的 其 他 线程 


A 


下 
Zap_other threads (Current) 7 
} 
spin unlock irq(&sighand->siglock); 


} 
/* 真正 的 退出 动作 ， 退 出 当前 线程 


task */ 
do exit (exit code); 
/* NOTREACHED */ 











下 面 来 看 看 do_exit 的 实现 : 




















NORET_ TYPE void do exit (long code) 

{ 
struct task struct *tsk = current; 
int group dead; 
profile task exit (tsk) 7 
WARN_ ON (blk_needs_flush _ plug (tsk)); 
/* 中 断 上 下 文 不 能 使 用 退出 ， 因 为 没有 进程 上 下 文 


有 
if (unlikely (in interrupt())) 
panic("Aiee, killing interrupt handler!"); 
/* Pid 为 


0， 即 内 核 的 


idle 进 程 。 这 个 


task 也 是 不 应 该 退出 的 


a 
if (unlikely(!tsk->pid)) 
panic("Attempted to kill the idle task!"); 


If do exit is called because this processes oopsed, it's possible 
that get fs() was left as KERNEL DS, so reset it to USER DS before 
continuing. Amongst other possible reasons, this is to prevent 

mm release()->clear child tid() from writing to a user-controlled 
* kernel address. 

$f 

set fs (USER DS); 

/* 如 果 


task 正 在 被 跟踪 如 


gqdb， 则 发 送 


ptrace 事 件 


ed 
ptrace event (PTRACE EVENT EXIT, code); 
validate creds for do exit (tsk); 
/* 
* We're taking recursive faults here in do exit. Safest is to just 
* leave this task alone and wait for reboot. 





task 退 出 的 时 候 ， 会 被 设置 上 
了 PE EXITING 标 志 。 如 果 发 现 此 时 


于 Lags 已 经 设置 了 该 标志 ， 则 说 


明 发 生 了 错误 。 此 时 就 要 按照 注释 所 说 的 ， 最 安全 的 方法 是 什么 都 不 做 ， 通 知 并 等 待 重启 


人 
if (unlikely(tsk->flags & PF EXITING)) { 
printk (KERN ALERT 
"Fixing recursive fault but reboot is needed!\n"); 


* We can do this unlocked here. The futex code uses 

* this flag just to verify whether the pi state 

* cleanup has been done or not. In the worst case it 
* loops once more. We pretend that the cleanup was 

* done as there is no way to return. Either the 

* OWNER DIED bit is set by now or we push the blocked 
* task into the wait for ever nirwana as well. 


tsk->flags |= PF EXITPIDONE; 
/* 将 当前 


七 aSk 设 置 为 不 可 中 断 的 状态 ， 然 后 放弃 


CPU. 


下 
Set current state (TASK_UNINTERRUPTIBLE) 
Schedule () 


和 
/* 如 果 当 前 
七 ask 是 中 断 线程 ， 即 每 个 


CPU 中 断 由 一 个 线程 来 处 理 ， 则 设置 对 应 的 中 断 停止 来 唤醒 本 线程 。 这 


是 一 个 编译 选项 ， 默 认 情况 下 是 关闭 的 - 


二 
exit irq thread(); 
ys 区 

七 aSk 设 置 退 出 标志 


PE _EXITING */ 

exit signals(tsk); /* sets PF EXITING */ 

/* 

* tsk->flags are checked in the futex code to protect against 

* an exiting task cleaning up the robust pi futexes. 

*f 

smp_mb(); 

raw Spin unlock wait (gtsk->pi lock); 

if (unlikely (in atomic())) 

Printk (KERN INFO "note: %s[%d] exited with preempt count %d\n", 

current->comm, task pid nr(current), 
preempt count ()); 

acct update integrals (tsk); 

人 sync mm's RSS info before statistics gathering */ 

* 该 


task 有 自己 的 内 存 空间 


让 
if (tsk->mm) 
sync_mm rss (tsk，tsk->mm) ; // 更 新 内 存 统计 计数 
/* 判断 整个 线程 组 是 否 都 已 经 退出 。 
小 


group dead = atomic dec and test (gtsk->signal->live); 
if (group dead) { 
/* 取消 高 精度 定时 器 


A 
hrtimer cancel (&tsk->signal->real timer); 
/* 删除 


task 的 内 部 定时 器 ， 对 应 系 





getitimer 和 


setitimer */ 
exit itimers (tsk->signal); 
if (tsk->mm) 
setmax mm hiwater rss(&tsk->signal->maxrss, tsk->mm); 


acct_ collect (code, group dead); 
/* ”如果 整 个 线程 组 都 已 经 退出 ， 则 释放 授权 资源 


Rf 
if (group dead) 
tty audit exit(); 
if (unlikely (tsk->audit context)) 
audit free (tsk); 
/* 设置 


task 的 退出 值 


4 
tsk->exit code = code; 
/* 释放 任务 统计 资源 


要 
taskstats exit (tsk, group dead); 
/* 
释放 


task 的 内 存 空间 。 


七 aSk 使 用 的 所 有 内 存 页 都 由 内 核 来 维护 。 对 于 用 户 程序 ， 如 果 忘 记 释 放 申 请 的 内 存 ， 


则 只 会 造成 用 户 程序 无 法 再 使 用 该 内 存 ， 因 为 内 核 认为 该 内 存 仍然 在 被 用 户 程序 使 用 。 当 


task 退 出 时 ， 内 核 


会 负责 释放 所 有 的 内 存 地 址 。 因 此 当 进 程 退 出 时 ， 所 有 申请 的 内 存 都 会 被 释放 ， 不 会 有 任何 的 内 存 泄漏 。 


sy 
exit mm(tsk); 
if (group dead) 
acct process(); 
trace_ sched process exit (tsk); 
/* 
检查 是 否 释放 了 


Semphore 资 源 ， 如 没有 释放 则 执行 


semphore 的 


Undo 操 作 。 这 点 用 于 保证 在 进程 意外 退 


出 时 ， 能 恢复 


Semphore 的 正确 状态 ， 也 可 以 用 于 预防 错误 的 程序 逻辑 所 导致 的 


Semphore 释 放 操作 进 漏 - 


w 
exit sem(tsk); 
/* 释放 共享 内 存 


exit_ shm(tsk); 
Er 
如 果 文 件 资源 没有 被 共享 ， 则 释放 所 有 的 文件 资源 。 即 使 用 户 程序 有 文件 泄漏 也 不 必 担 心 ， 一 旦 


task 退 


出 ， 文 件 资源 都 会 得 到 正确 的 释放 -因为 内 核 维护 了 所 有 的 、 打 开 的 文件 。 


本 
exit files(tsk); 
/* 释放 


task 的 文件 系统 资源 ， 如 当前 目录 、 根 目录 等 


4 
exit fs (tsk) 7 
check stack _ usage () 7 
/* 释放 


七 aSk 资 源 ， 如 


TSS 段 等 


本 人 
exit thread() 
fe 
* Flush inherited counters to the parent - before the parent 
* gets woken up by child-exit notifications. 
四 


* because of cgroup mode, must be called before cgroup exit() 
*/ 

perf event exit task(tsk); 

/* 从 控制 组 退出 ， 并 释放 相关 资源 


cgroup exit (tsk, 1); 
/* 如 果 线 程 组 都 已 经 退出 ， 则 断 开 控制 终端 即 


tty */ 
if (group dead) 
disassociate ctty(1); 
/* 后 面 仍然 是 一 些 


task 退 出 的 清理 工作 ， 因 与 本 节 关系 不 大 ， 所 以 在 此 不 再 一 一 列 出 了 


A 








从 exit 的 源码 可 以 得 知 ， 即 使 应 

















程序 在 应 








层 有 内 存 泄漏 或 文件 句柄 泄漏 也 不 必 担 心 ， 当 进程 退出 时 ， 内 核 的 exit_group 调 























将 会 默默 地 在 后 面 做 着 清理 了 


[ 作 ， 释 放 所 有 内 存 ， 关 闭 所 有 文件 ， 以 及 其 














3.3 ”atexit 介 绍 


3.3.1 ”使 用 atexit 








atexit 用 于 注册 进程 正常 退出 时 的 回调 函数 。 若 注册 了 多 个 回调 函数 ， 最 后 的 调用 顺序 与 注册 顺序 
相反 ， 与 我 们 熟悉 的 栈 操作 类 似 ， 先 入 后 出 。 





#include <stdlib.h> 
int atexit (void (*function) (voidqd)); 





下 面 来 看 一 个 简单 的 例子 : 





#include <stdlib.h> 
#include <stdio.h> 
static void callbackl (void) 


{ 
} 


static void callback2 (void) 


{ 
} 


static void callback3 (void) 


{ 
} 


int main (void) 


{ 


printf ("callbackl\n"); 


printf ("callback2\n"); 








printf ("callback3\n"); 


callback1); 
callback2); 
callback3); 
"main exit\n"); 


atexit 
atexit 
atexit 
printf 





~ 





它 的 运行 结果 如 下 : 





main exit 
callback3 
callback2 
callbackl 





从 上 面 的 代码 输出 可 以 看 出 ， 我 们 顺序 地 注册 callback1、callback2 和 callback3， 当 进程 退出 时 ， 其 
调用 顺序 为 callback3、callback2 和 callback1。 


3.3.2 atexit 的 局 限 性 





3.3.1 节 介绍 atexit 的 基本 用 法 时 提 到 过 ， 使 用 atexit 注 册 的 退出 函数 是 在 进程 正常 退出 时 ， 才 会 被 调 
用 。 这 里 的 正常 退出 是 指 ， 使 用 exit 退 出 或 使 用 main 中 最 后 的 return 语 名 退出。 若是 因为 收 到 信和 号 而 导致 
程序 退出 ，atexit 注 册 的 退出 函数 则 不 会 被 调用 。 下 面 我 们 通过 一 个 测试 程序 来 验证 这 一 观点 : 




















#include <stdlib.h> 
#include <stdio.h> 
#include <unistd.h> 
static void callbackl (void) 


{ 
} 


int main (voidgd) 


{ 


printf ("callbackl\n"); 


atexit (callback1) ， 
while (1) { 

Sleep (1); 
} 


printf ("main exit\n"); 
return 0; 








然后 编译 运行 ， 使 用 另 一 个 控制 台 给 其 发 送信 号 : 





[fgao@fgao ik8]#killall atexit _ Signal 





我 们 会 发 现 atexit 注 册 的 退出 函数 并 没有 被 调用 : 








[fgao@fgao chapter3]#./atexit signal; 
Terminated 





为 什么 只 有 在 正 


党 
实现 ， 就 可 以 得 到 答案 








退出 的 时 候 ，atexit 注 册 的 退出 函数 才能 被 调用 呢 ? 下 面 我们 来 分 析 atexit 的 源码 
了 


o 


3.3.3 ”atexit 的 实现 机 制 


让 我 们 带 着 疑问 来 分 析 glibc 中 的 atexit 涯 码 : 





int 
#ifndef atexit 
attribute hidden 
#endif 
atexit (void (*func) (void) ) 
{ 
/* dso handq1le 是 动态 共享 对 象 的 句柄 ， 此 处 可 以 略 过 


*#/ 
return _cxa atexit ((void (*) (void *)) func, NULL, 
& dso handle == NULL ? NULL : _ dso handle); 
} 
int 
__Cxa atexit (void (*func) (void *), void *arg, void *dqd) 


/* exit funcs 为 退出 函数 的 链表 


*/ return _ internal atexit (func, arg, d, & exit funcs); 
} 
也 而 起 
attribute hidden 
__ internal atexit (void (*func) (void *), void *arg, void *qd, 
struct exit function list **]istp) 





/* 在 退出 函数 链表 中 ， 得 到 一 个 新 的 节点 


< 
struct exit function *new = new exitfn (listp); 
if (new == NULL) 


return -1; 
#ifdef PTR MANGLE 
PTR MANGLE (func); 
#endif 
/* 初始 化 这 个 节点 ， 将 函数 及 其 参数 赋 给 这 个 节点 





大 

/ 

new->func.cxa.fn = (void (*) (void *, int)) func; 
new->func.cxa.arg = arg; 

new->func.cxa.dso handle = qd; 

atomic write barrier (); 

new->flavor = ef cxa; 

return 0; 





上 面 的 代码 揭示 了 atexit 是 如 何 把 函数 注册 到 退出 函数 链表 中 的 。 那 么 ， 这 些 函 数 又 是 何 时 被 调用 
的 呢 ? 回忆 atexit 的 介绍 ， 退 出 注册 函数 只 有 在 程序 正常 退出 或 调用 exit 时 才 会 被 执行 。 程 序 正 常 退出 
时 ， 系 统 就 会 调用 exit。 因 此 ， 问 题 的 关键 就 在 于 exit 函 数 了 : 

















void 
exit (int status) 
{ 
__run exit handlers (status, & exit funcs, true); 


} 





在 这 里 ， run exit handlers 会 遍历 ”exit foncs， 一 一 调用 注册 的 退出 函数 ， 在 此 就 不 再 罗列 其 代 
码 了 。 从 atexit 的 实现 机 制 上 进行 分 析 ， 我 们 可 以 得 出 atexit 的 实现 是 依赖 于 C 库 的 代码 的 。 当 进程 收 到 


言 号 时 ， 如 果 没 有 注册 对 应 的 信号 处 理 函 数 ， 那 么 内 核 就 会 执行 信号 的 默认 动作 ， 一 般 是 直接 终止 进 


























程 。 这 时 ， 进 程 的 退出 完全 上 
函数 了 。 


日 内 核 来 完成 ， 自 然 不 会 调用 到 C 库 的 exit 函 数 ， 也 就 无 法 调用 六 


E 册 的 退出 


3.4 小 心 使 用 环境 变量 





Linux 环 境 下 ， 程 序 在 启动 的 时 候 都 会 从 shell 环 境 下 继承 当前 的 环境 变量 ， 如 PATH、HOME、TZ 
等 。 我 们 也 可 以 通过 C 库 的 接口 来 增加 、 修 改 或 删除 当前 进程 的 环境 变量 ， 示 例如 下 : 














#include <stdlib.h> 
int putenv (char *string); 











putenv 用 于 增加 或 修改 当前 的 环境 变量 。string 的 格式 为 “名字 = 值 ”。 如 果 当 前 环境 变量 没有 该 名 称 
的 环境 变量 ， 则 增加 这 个 新 的 环境 变量 ， 如 果 已 经 存在 ， 则 使 用 新 值 。 看 似 功 能 很 简单 ， 但 实际 上 使 
用 这 个 接口 时 ， 却 很 容易 犯错 。 请 看 下 面 的 代码 : 














#include <stdlib.h> 
#include <stdio.h> 
static void set env string (void) 
{ 
char test env[] = "test env=test"; 
if (0 != putenv(test env)) { 
printf ("fail to putenv\n"); 


printf("1. The test evn string is Ss\n", getenv ("test env")); 


static void show env _ string (void) 








BrintE 


2. The test env string is %s\n", getenv ("test env")); 
int main() 
set env string(); 


show env string();return 0; 


} 








然后 编译 ， 查 看 输出 结果 : 


The test evn string is test 
The test env string is (null) 


Fo 请 








结果 有 点 出 人 意料 ， 为 什么 在 set_env_string 中 可 以 得 到 我 们 设置 的 环境 变量 ， 而 在 show_env_string 
中 却 不 行 呢 ? 





原因 在 于 使 用 putenv 添 加 环境 变量 时 ， 参 数 直 接 被 当 作 环 境 变量 的 一 部 分 了 。 对 于 本 例 而 
言 ，set_env_string 中 的 test_env 数 组 直接 被 环境 变量 引用 了 。 而 test_env 是 一 个 局 部 变量 ， 在 执行 
set_env_string 的 时 候 ，test_env 已 经 不 存在 了 ， 对 应 栈 上 的 内 存 会 在 后 面 的 函数 调用 中 使 用 ， 并 存 入 其 
他 值 。 因 此 ， 在 进入 show_env_string 的 时 候 ， 就 无 法 得 到 正确 的 值 了 。 



































者 曾经 修改 过 一 个 因为 putenv 引 起 的 bug， 当 时 也 是 费 了 很 大 一 番 力 气 才 找到 根本 原因 ， 所 以 颇 
为 气愤 当时 的 开发 人 员 为 什么 在 使 用 putenv 的 时 候 ， 不 认真 阅读 该 接口 的 说 明 。Martin Golding 曾 说 过 一 
句 话 “编程 的 时 候 ， 要 总 是 想 着 那个 维护 你 代码 的 人 会 是 一 个 知道 你 住 在 哪儿 的 、 有 暴力 倾向 的 精神 病 
患者 ”。 











如 果 非 要 用 putenv 来 设置 环境 变量 ， 就 必须 要 保证 参数 是 一 个 长 期 存在 的 内 容 。 因 此 ， 只 能 选择 全 














局 变量 、 和 常量 或 动态 内 存 等 。 为 了 避免 犯错 ， 我 们 应 该 尽量 使 用 另外 一 个 接口 setenv， 代 码 如 下 : 





#include <stdlib.h> 
int setenv(const char *name, const char *value, int overwrite); 





参数 说 明 : 





-name: 要 加 入 的 环境 变量 名 称 。 


.value: 该 环境 变量 的 值 。 


“Overwrite: 











用 于 指示 是 否 窗 盖 已 存在 的 重 名 环境 变量 。 


还 是 使 用 上 文 的 例子 ， 只 不 过 我 们 将 putenv 换 为 setenv， 代 码 如 下 : 





#inclugde <stdlib.h> 
#inclugde <stdio.h> 
static void set env string (void) 


{ 


setenv("test env", "test", 1); 


BEintf (Vl 


} 


The test evn string is %$s\n", getenv("test env")); 


static void show env _ string (void) 


{ 


PeintE (2 


int main() 


{ 





The test env string is %$s\n", getenv("test env")); 


set env string(); 
show env string(); 





return 0; 
} 
这 次 的 运行 结果 就 是 我 们 预期 的 结果 了 : 








DP 


The test evn string is test 
The test env string is test 





3.$ ”使 用 动态 库 





在 平时 的 编程 工作 中 ， 除 了 C 库 ， 还 会 用 到 大 量 的 库 文 件 ， 其 中 绝 大 部 分 都 是 以 动态 库 的 方式 来 提 
供 服务 的 。 





3.5.1 动态 库 与 静态 库 














一 般 情况 下 ， 库 文件 的 开发 者 会 同时 提供 动态 库 和 静态 库 两 个 版 本 ， 它 们 都 有 各 自 的 优 缺 点 。 融 
态 库 在 链接 阶段 ， 会 被 直接 链接 进 最 终 的 二 进 制 文 件 中 ， 因 此 最 终生 成 的 二 进 制 文件 体积 会 比较 大 ， 
但 是 可 以 不 再 依赖 于 库 文件 。 而 动态 库 并 不 是 被 链接 到 文件 中 的 ， 只 是 保存 了 依赖 关系 ， 因 此 最 终生 
成 的 二 进 制 文件 体积 较 小 ， 但 是 在 运行 阶段 需要 加 载 动态 库 。 

















3.$.2 ”编译 生成 和 使 用 动态 库 























首先 ， 我 们 来 编译 并 生成 一 个 动态 库 : 





#include <stdlib.h> 
#include <stdio.h> 
void dynamic lib call (void) 
{ 
Brintf(vaynamic Lib callNMna) 7 











编译 生成 动态 库 与 编译 普通 的 可 执行 程序 略 有 不 同 ， 如 下 所 示 : 





gcc -Wall -shared 4 5 2 dlipb.c -o libdlib.so 








其 中 多 了 一 个 -shared 选 项 ， 该 选项 用 于 指示 gcc 生 成 动态 库 。 


然后 再 编写 一 个 简单 例子 ， 来 使 用 这 个 动态 库 ， 代 码 如 下 : 











#include <stdlib.h> 
#include <stdio.h> 
extern void dynamic lib call (void); 
int main (void) 
{ 
dynamic lib call(); 
return 0; 


} 














下 面 我 们 利用 前 面 的 动态 库 来 生成 最 终 的 可 执行 文件 gcc-Wall 4 5 2 main.c-o test dlib-L./-ldlib。 其 中 ，-] 用 
于 指示 生成 文件 依赖 的 库 ， 本 例 依赖 于 libdlib.so， 因 此 为 -1dlib; -L 与 -类 似 ，-L 用 于 指示 gcc 在 哪个 目录 中 查找 依 
赖 的 库 文件 。 








让 我 们 运行 这 个 test_dlib 看 看 结果 如 何 : 





[fgao@ubuntu chapter3]#./test dlib 
./test dlib: error while loading shared libraries: libdlib.so: cannot open shared object file: No such file or directory 


























为 什么 会 报告 出 错 ， 找 不 到 这 个 libdlib.so 呢 ?前 面 明明 已 经 使 用 -L 指 定 了 库 文件 在 当前 目录 中 ， 并 且 这 个 库 
文件 也 确实 存在 于 当前 目录 中 啊 。 这 是 怎么 回 事 呢 ? 


让 我 们 使 用 ldd 来 查看 test_ lib 的 依赖 库 ， 代 码 如 下 ; 





[fgao@ubuntu chapter3]#1ldd test dlib 
linux-gate.so.1 => (0xb7785000) 
libdlib.so => not found 
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb75ce000) 
/lib/1ld-linux.so.2 (0xb7786000) 








确实 显示 无 法 找到 libdlib.so。 原 因 在 于 -L 只 是 在 gcc 编 译 的 过 程 中 指示 库 的 位 置 ， 而 在 程序 运行 的 时 候 ， 动 态 
库 的 加 载 路 径 默 认为 /lib 和 /usr/ib。 在 Linux 环 境 下 ， 还 可 以 通过 /etc/1d.so.conf 配 置 文件 和 环境 变量 
LD_LIBRARY PATH 指示 额外 的 动态 库 路 径 。 








为 简单 起 见 ， 我 们 在 这 里 将 libdlib.so 复 制 到 /usr/lib 目 录 下 ， 再 运行 test_dlib 试 试 : 








[root@ubuntu lib]l#cp /home/fgao/works/my git codes/my books/ungderstanding apue/sample codes/chapter3/libdlib.so . 
[fgao@ubuntu chapter3]#./test dlib 
dynamic lib call 


现在 .test_dlib 顺 利 执行 了 ， 并 成 功 调 用 了 动态 库 中 的 dynamic_ lib_call 函 数 。 





























上 面 的 例子 中 ， 动 态 库 是 由 系统 自动 加 载 的 ， 所 以 需要 将 动态 库 放 在 指定 的 目录 下 。 然 而 ，C 库 还 提供 了 
dlopen 等 接口 来 支持 手工 加 载 动态 库 的 功能 ， 代 码 如 下 : 























#include <stdlib.h> 

#include <stdio.h> 

#include <dlfcn.h> 

int main() 

{ 
void *dlib = dlopen("./libdlib.so", RTILD NOW); 
if (!dlib) { 

printf ("dlopen failed\n"); 

return -1; 


} 

void (*dfunc) (void) = dlsym(dlib, "dynamic lib call"); 
EA) 

printf("dlsym failed\n"); 

return -1; 


} 
dfunc(); 
dlclose (dlib); 
return 0; 























编译 代码 gcc-Wall 4 5 2_main mlib.c-ldl-o test_mlib， 需 要 使 用 -1d1l 选 项 来 指定 依赖 的 动态 库 libdl.so。 





F 





下 面 来 看 一 下 输出 结果 : 

















[fgao@ubuntu chapter3]#./test mlib 
dynamic lib call 











可 以 看 出 ， 我 们 已 经 成 功 地 使 用 手工 来 加 载 动态 库 ， 并 完成 了 动态 库 中 的 函数 调用 。 








介绍 完 动 态 库 的 两 种 加 载 方法 ， 我 们 可 以 对 比 一 下 两 者 的 优 缺 点 。 对 于 自动 加 载 ， 处 理 起 来 比较 简单 ， 而 手 
工 加 载 需要 编写 额外 的 代码 ， 但 正 是 这 些 额外 的 代码 提供 了 更 多 的 动态 库 的 可 控 性 

















O 





3.5.3 -有 程 犀 的 " 平 请 无 颖 ”升级 








3.5.1 节 中 ， 对 比 了 动态 库 和 静态 库 的 优 缺 点 。 其 中 动态 库 的 一 个 重要 优点 就 是 ， 可 执行 程序 并 不 
包含 动态 库 中 的 任何 指令 ， 而 是 在 运行 时 加 载 动态 库 并 完成 调用 。 这 就 给 我 们 提供 了 升级 动态 库 的 机 
会 。 只 要 保证 接口 不 变 ， 使 用 新 版 本 的 动态 库 蔡 换 原来 的 动态 库 ， 就 完成 了 动态 库 的 升级 。 更 新 完 库 
文件 以 后 启动 的 可 执行 程序 都 会 使 用 新 的 动态 库 。 














这 样 的 更 新 方法 只 能 够 影响 更 新 以 后 启动 的 程序 ， 对 于 正在 运行 的 程序 则 无 法 产生 效果 ， 因 为 程 
序 在 运行 时 ， 旧 的 动态 库 文 件 已 经 加 载 到 内 存 中 了 。 我 们 只 能 更 新 位 于 磁盘 上 的 动态 库 的 物理 文件 ， 
而 不 能 影响 已 经 位 于 内 存 中 的 库 了 。 














我 们 是 否 可 以 做 得 更 好 呢 ? 对 于 服务 程序 来 说 ， 重 局 会 付出 很 大 的 代价 并 带 来 糟糕 的 用 户 体验 。 
那么 ， 能 否 让 运行 中 的 服务 程序 也 能 在 升级 库 以 后 使 用 新 的 指令 ， 做 到 "平滑 无 颖 ”的 升级 呢 ? 这 就 需 
要 使 用 前 面 介绍 的 手工 加 载 动态 库 的 方法 了 。 



































下 面 的 伪 代 码 将 给 出 一 个 比较 简单 的 解决 方案 。 








1) 使 用 一 个 结构 体 来 管理 动态 库 的 接口 : 














struct dlipb manager {voiqd *dlib handle; // 保 存 动态 库 的 句柄 


int (service func) (void *);int (service func2) (void *) 7 
} g dlib manager; 
/* 9 dlib managet 作 为 动态 库 接口 的 全 局 变量 


大 
struct dlib manager *g dlib manager; 














2) 利用 dlopen、dlsym 等 来 加 载 动态 库 ， 更 新 接口 。 重 新 申请 新 的 内 存 ， 来 保存 新 的 动态 库 接口 : 








/* 更 新 动态 库 接口 


大 

/ 

struct dlib manager *new manager = malloc (sizeof (*new manager)); 
new manager->dlib handle = dlopen ("libupgrade.so", RTLD LAZY); 

new manager->service func = dlsym(g dlib handle, "service call"); 
new manager->service func2 = dlsym(g dlib handle, "service call2"); 
/* 在 多 核 环境 下 ， 使 用 内 存 屏障 ， 以 保证 在 交换 

















new_manager 和 


g_dlib manager 时 ， 


new_managere 已 经 


«7 


wmb () 
/* 交 换 新 指针 与 当前 正在 使 用 的 接口 指针 





池 
至 
Fay 


因为 目前 ， 无 论 是 新 指针 还 是 旧 指针 都 是 有 效 的 接口 ， 所 以 并 不 会 对 业务 产生 影响 


4 
swap (new manager, g dlib manager); 
/* 交 换 完成 以 后 ， 新 的 请 求 都 会 交 由 新 接口 来 处 理 


由 于 当前 旧 接 口 仍然 可 能 正在 使 用 中 ， 所 以 要 使 用 推迟 释放 或 是 等 待 正 在 服务 的 接口 完成 





大 
delay_ free (new manager); 











3) 在 调用 服务 接口 时 ， 要 利用 局 部 变量 保存 服务 接口 : 





struct dlib manager *local dlib manager = g dlib manager; 
local dlipb manager->service funcl (data); 
local dlib manager->service func2 (data); 

















之 所 以 这 里 使 用 局 部 变量 来 进行 接口 调用 ， 是 为 了 避免 在 调用 了 一 部 分 接口 后 ，g_dlib_manager 才 
发 生 更 新 ， 从 而 导致 前 后 的 服务 接口 属于 不 同 的 动态 库 ， 造 成 不 可 预料 的 问题 。 通 过 临时 变量 来 保存 
服务 接口 ， 能 确保 所 有 接口 的 一 致 性 。 























4) 释放 旧 接 口 的 关键 在 于 ， 要 保证 没有 旧 接 口 正 在 被 使 用 。 根 据 自己 的 业务 ， 找 到 一 个 时 间 点 
一 一 在 这 个 时 间 点 上 ， 上 所 有 的 线程 〈 准 确 地 说 是 请 求 流程 ) 都 已 经 服务 过 一 次 。 这 时 ， 新 来 的 请 求 就 
会 使 用 新 的 接口 ， 于 是 我 们 也 就 可 以 安全 地 释放 上 接口 了 。 




















其 实 整个 实现 方案 是 借鉴 了 Linux 内 核 的 RCU 实 现 方式 。 通 过 这 种 方法 ， 可 以 进行 “平滑 无 颖 "的 升 
级 ， 而 不 影响 运行 状态 下 的 业务 功能 。 


3.6 ”避免 内 存 问题 





在 编程 的 错误 中 ， 内 存 问题 无 颖 占据 了 很 大 的 比例 。 而 且 内 存 问 题 比较 难 查 ， 出 现 问 题 的 “ 案 发 现 
场 " 与 真正 的 “凶手 ”往往 隔 着 十 万 八 千里 ， 甚 至 完全 没有 关系 。 对 于 初学 者 来 说 ， 解 决 这 样 的 问题 往往 
要 浪费 大 量 的 时 间 。 因 此 ， 我 们 应 该 在 编写 代码 的 初始 阶段 ， 就 要 注意 避 开 茶 些 代码 “陷阱 ”。 问 题 发 
现 得 越 早 ， 代 价 也 就 越 小 。 





3.6.1 的 罚 的 realloc 




















对 于 良好 的 代码 风格 ， 有 一 项 很 重要 的 要 求 是 一 个 函数 只 专注 于 做 一 件 事 情 。 如 果 该 函数 像 瑞士 
军刀 一 样 能 实现 多 个 功能 ， 那 基本 上 可 以 断言 这 不 是 一 个 设计 良好 的 函数 。 





C 库 中 的 realloc 函 数 就 是 一 个 典型 的 反面 教材 : 


#include <stdlib.h> 
void *realloc(void *ptr, size t size); 


realloc 可 以 将 ptr 指 向 的 内 存 调整 为 size 大 小 。 这 个 功能 看 上 去 很 明确 ， 其 实则 不 然 ， 其 一 共有 三 种 
不 同 的 行为 : 





:参数 ptr 为 NULL， 而 size 不 为 0， 则 等 同 于 malloc (size) 。 
.参数 ptr 不 为 NULL， 而 size 为 0， 则 等 同 于 free (ptr〉。 

:参数 ptr 和 size 均 不 为 0， 其 行为 类 似 于 free (ptr) ; malloc (size) 。 

有 着 三 种 不 同行 为 的 realloc， 很 容易 给 代码 引入 bug。 下 面 举 一 个 例子 来 说 明 : 


void * Ptr = realloc(ptr, new size); 
| 
/ /错误 处 理 


这 里 就 会 因为 realloc 的 第 三 种 行为 引入 一 个 bug。 当 realloc 分 配 内 存 失败 的 时 候 ，ptr 会 返回 NULL。 


但 是 这 时 ptr 原 来 指向 的 内 存 并 没有 被 释放 ， 而 ptr 却 已 经 被 赋值 为 NULL 了 ， 这 就 造成 了 ptr 原 有 内 存 泄 
漏 。 























正确 的 做 法 应 该 是 : 





void * new ptr = realloc(ptr, new size) 
if (!Inew ptr) { 
/ /错误 处 理 


} 
ptr = new ptr 








realloc 只 有 在 分 配 内 存 成 功 的 情况 下 ， 才 会 让 ptr 等 于 new_ptr。 这 样 ， 在 分 配 内 存 失败 的 情 ; 
下 ，ptr 指 向 的 内 存 并 不 会 丢失 。 


总 








realloc 使 用 不 当 还 会 引发 其 他 几 种 bug， 在 此 就 不 一 一 罗列 了 。 需 要 吸取 的 教训 就 是 ， 慎 用 
realloc， 甚 至 最 好 不 用 realloc。 如 果真 的 需要 使 用 realloc， 一 定 要 确保 在 realloc 的 三 种 行为 下 代码 都 可 
以 正常 工作 。 








3.6.2 ”如 何 防 止 内 存 越 界 





在 日 常 的 编程 中 ， 初 学 者 往往 会 遇 到 内 存 越界 所 引发 的 问题 。 其 实 ， 通 过 民 好 的 编程 习惯 基本 上 
是 可 以 避免 内 存 越界 问题 的 。 防 范 的 根本 思想 在 于 在 对 缓冲 区 《一 般 为 数组 ) 进行 揽 贝 前 ， 要 保证 复 
制 的 长 度 不 要 超过 缓冲 区 的 空间 大 小 。 比 如 在 memcpy 前 ， 要 检查 目的 地 址 是 否 有 足够 的 空间 。 


使 用 宏 或 sizeof 可 保证 缓冲 长 度 的 一 致 性 ; 





char dst buf[64]; 
memcpy (dst buf, src buf,64); 





当 缓 冲 大 小 改变 为 32 的 时 候 ， 需 要 改动 两 处 代码 。 一 旦 忘记 修改 memcpy 处 的 拷贝 长 度 ， 就 会 造成 
内 存 越界 。 


对 上 面 的 代码 进行 改善 : 





#define BUF SIZE 64 
char dst buf{[BUF SIZE]; 
memcpy (dst buf, src buf, BUF SIZE); 











或 





char dst buf[64]; 
memcpy (dst buf, src buf, sizeof(dst buf)); 





这 样 就 可 以 做 到 缓存 大 小 和 复制 长 度 的 同步 修改 。 











使 用 安全 的 库 函 数 也 可 以 保证 复制 的 长 度 不 超过 缓冲 区 的 空间 ， 下 面 来 介绍 4 种 库 函 数 。 





1) 使 用 strncat 代 蔡 strcat， 代 码 如 下 : 





#include <string.h> 
char *strncat (char *dest, const char *src, size t n); 





从 src 中 最 多 追加 np 个 字符 到 dest 字 符 串 的 后 面 。 需 要 注意 的 是 ， 当 src 包 含 npn 个 以 上 的 字符 时 ，dest 的 
空间 至 少 为 strlen (dest) +n+1， 因 为 该 函数 还 会 追加 字符 串 结 束 符 \0' 到 dest 后 面 。 








下 面 的 示例 为 正确 的 写法 : 





char dest[20] = "hello"; 
strncat (dest, src, sizeof (dest)-strlen (dest)-1); 





一 定 要 记 住 给 \0' 留 下 空间 。 


2) 使 用 strncpy 代 蔡 strepy， 代 码 如 下 : 





#include <string.h> 
char *strncpy (char *dest, const char *src, Size t n); 





从 src 中 最 多 复制 n 个 字符 到 dest 字 符 串 中 。 与 strncat 相 同 的 是 ， 当 grec 包含 n 个 以 上 的 字符 时 ，dest 的 
空间 需要 为 nt1， 因 为 该 函数 还 会 再 复制 一 个 字符 串 结束 符 \0'。 








下 面 的 示例 为 正确 的 写法 : 





char dest[20]; 
strncpy (dest, src, sizeof (dest)-1); 





3) 使 用 snprintf 代 蔡 sprintf， 代 码 如 下 : 





#include <stdio.h> 
int snprintf(char *str, size 七 size, const char *format, ...); 





snprintf 比 前 面 两 个 函数 strncat 和 strncpy 更 为 友好 ， 在 往 str 中 写 数据 时 ， 最 多 会 写 入 n 字 节 ， 其 中 已 
包括 字符 串 结束 符 \0'。 


正确 的 示例 代码 如 下 : 





char str[20]; 
snprintf (str, sizeof (str), "%s", dest0); 





4) 使 用 fgets 代 蔡 gets， 代 码 如 下 : 





#include <stdio.h> 
char xfgets (char *s, int Size FILE xstream) 








危险 的 gets 函 数 从 来 不 检查 缓冲 区 的 大 小 ， 并 且 还 是 从 标准 输入 中 读 取 数据 ， 这 是 极其 危险 的 行 
为 。 再 大 的 缓存 空间 也 无 法 满足 永 无 终止 的 标准 输入 ， 因 此 一 定 要 使 用 fgets 代 蔡 。 











fgets 最 多 会 复制 size-1 字 节 到 缓存 s 中 ， 并 且 会 在 最 后 一 个 字符 后 面 追加 \0'。 因 此 如 果 要 读 取 标 准 输 
入 ， 正 确 的 示例 代码 如 下 : 





char str[20]; 
fgets (str, sizeof (str), stdin): 











由 于 历史 原因 ， 标 准 C 库 中 还 存在 其 他 不 安全 的 接口 ， 不 过 后 来 C 库 中 也 发 展 了 相应 的 安全 接口 。 
在 日 第 的 编程 中 ， 除 非特 殊 情 况 ， 都 要 使 用 安全 函数 来 蔡 代 非 安 全 函数 的 调用 。 


3.6.3 如何 定位 内 存 问题 


前 文 主要 介绍 了 如 何 防范 和 避免 内 存 问题 。 





何 定 位 它 ， 如 何 找 到 根本 原因 呢 ? 





但 是 如 果 程 序 里 面 真 的 出 现 了 内 存 问 题 ， 





我 们 又 该 如 


工 欲 善 其 事 ， 必 先 利 其 器 。valgrind 作 为 一 个 免费 且 优 秀 的 工具 包 ， 提 供 了 很 多 有 用 的 功能 ， 其 中 


最 有 名 的 就 是 对 内 存 问题 的 检测 和 定位 。 


请 看 下 面 的 代码 : 





#include <stdlib.h> 
#include <stdio.h> 
#include <string.h> 
static void mem leakl (void) 


{ 
} 


static void mem leak2 (void) 


{ 
} 


static void mem overrunl (void) 


{ 


char xp = malloc(1); 





FILE *fp = fopen("test.txt", “w"); 


char xp = malloc(1); 
*(short*)p = 2; 
free (PD) 


static void mem overrun2 (void) 
{ 

char arrayl[l5]; 

strcpy (array, "hello"); 
static void mem double free (void) 
{ 

char xp = malloc(1); 

free (p); 

free (p); 
} 


static void mem free wild pointer (void) 


Char: p> 
free (p); 


int main() 


mem leakl (); 

mem leak2(); 

mem overrun] (); 

mem overrun2 (); 

mem double free(); 

mem free wild pointer(); 
return 0; 





上 面 的 代码 中 包含 了 六 种 常见 的 内 存 问题 : 


:动态 内 存 泄漏 ; 


资源 泄漏 ， 代 码 中 以 文件 描述 符 为 例 ; 


动态 内 存 越界 ; 


.数组 越界 ; 


.动态 内 存 double free; 
使 用 时 指针 。 


下 面 来 看 看 怎样 执行 valgrind 来 检测 内 存 错误 : 











valgrind --track-fds=yes --leak-check=full --undef-value-errors=yes ./mem test 





这 段 代 码 中 各 项 的 具体 含义 ， 可 以 参看 valgrind--heljp， 其 中 有 些 option 默 认 就 是 打开 的 ， 不 过 笔者 
习惯 于 明确 地 使 用 option， 以 示 清 晰 。 











下 面 来 看 看 执行 后 的 报告 : 








==2326== Memcheck, a memory error detector 

==2326== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. 
==2326== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info 
==2326== Command: ./mem test 

==2326== 

/* 此 处 检测 到 了 动态 内 存 的 越界 ， 提 示 





Invaliqd write*/ 
==2326== Invalid write of size 2 
==2326== at 0x80484B4: mem overrunl1 (in /home/fgao/works/test/a.out) 
==2326== by 0x8048553: main (in /home/fgao/works/test/a.out) 
==2326== Address 0x40211f0 is 0 bytes inside a block of size 1 alloc'd 
==2326== at 0x4005BDC: malloc (vg _ replace malloc.c:195) 
==2326== by 0x80484AD: mem _ overrun1l (in /home/fgao/works/test/a.out) 
==2326== by 0x8048553: main (in /home/fgao/works/test/a.out) 
==2326== 

/* 此 处 检测 到 了 


double free 的 问题 ,提示 


Invalid Free */ 

==2326== Invalid free() / delete / delete[] 

==2326== at 0X40057F6: free (Vg_ replace malloc.c:325) 

==2326== by 0x8048514: mem double free (in /home/fgao/works/test/a.out) 
==2326== by 0x804855D: main (in /home/fgao/works/test/a.out) 

==2326== Address 0x4021228 is 0 bytes inside a block of size 1 free'd 
==2326== at 0x40057F6: free (vg replace malloc.c:325) 

==2326== by 0x8048509: mem double free (in /home/fgao/works/test/a.out) 
==2326== by 0x804855D: main (in /home/fgao/works/test/a.out) 

==2326== 
/* 此 处 检测 到 了 未 初始 化 变量 的 问题 








*/ 
==2326== Conditional jump or move depends on uninitialised value(s) 
==2326== at 0x40057B6: free (vg replace malloc.c:325) 
==2326== by 0x804853C: mem free wild pointer (in /home/fgao/works/test/a.out) 
==2326== by 0x8048562: main (in /home/fgao/works/test/a.out) 
==2326== 
/* 此 处 检测 到 了 非法 使 用 时 指针 

















大 

/ 

==2326== Invalid free() / delete / delete[] 

==2326== at 0x40057F6: free (vg _ replace malloc.c:325) 

==2326== by 0x804853C: mem free wild pointer (in /home/fgao/works/test/a.out) 
==2326== by 0x8048562: main (in /home/fgao/works/test/a.out) 

==2326== Address 0x4021228 is 0 bytes inside a block of size 1 free'd 
==2326== at 0x40057F6: free (vg replace malloc.c:325) 

==2326== by 0x8048509: mem double free (in /home/fgao/works/test/a.out) 





==2326== by 0x804855D: main (in /home/fgao/works/test/a.out) 


==2326== 
==2326== 
到 了 文件 指针 资源 的 泄漏 ， 下 面 提示 说 有 









4 个 文件 描述 符 在 退出 时 仍 是 打开 的 描述 


2 无 须 关 心 ， 通 过 报告 ， 可 以 发 现 程序 中 自己 明确 打开 的 文件 描述 符 没 有 关闭 





wah 
==2326== FILE DESCRIPTORS: 4 open at exit. 
==2326== Open file descriptor 3: test.txt 

















==2326== at 0x68D613: _ open nocancel (in /lib/libc-2.12.so) 
==2326== by 0x61F8EC: fopen internal (in /lib/libc-2.12.so) 
==2326== by 0x61F94B: fopen@Q@GLIBC 2.1 (in /lib/libc-2.12.so) 
==2326== by 0x8048496: mem leak2 (in /home/fgao/works/test/a.out) 


==2326== by 0x804854E: main (in /home/fgao/works/test/a. 





==2326== 
==2326== Open file descriptor 2: /dev/pts/4 
==2326== <inherited from parent> 

==2326== 
==2326== Open file descriptor 1: /dev/pts/4 
==2326== <inherited from parent> 

==2326== 
==2326== Open file descriptor 0: /dev/pts/4 
==2326== <inherited from parent> 

==2326== 

==2326== 

/* 堆 信 息 的 总 结 ， 一 共 调用 了 












































alloc, 


free。 之 所 以 正好 相等 ， 是 因为 上 面 有 一 个 函数 少 了 





free， 有 一 个 函数 正好 又 多 了 一 个 


free */ 

==2326== HEAP SUMMARY: 

==2326== in use at exit: 353 bytes in 2 blocks 

==2326== total heap usage: 4 allocs, 4 frees, 355 bytes 
==2326== 

/* 检测 到 一 字 节 的 内 存 泄漏 





out) 


allocated 


人 
==2326== 1 bytes in 1 blocks are definitely lost in loss record 1 of 2 
==2326== at 0x4005BDC: malloc (vg _ replace malloc.c:195) 
==2326== by 0x8048475: mem leakl (in /home/fgao/works/test/a.out) 
==2326== by 0x8048549: main (in /home/fgao/works/test/a.out) 
==2326== 

/* 内 存 泄漏 的 总 结 


大 

/ 

==2326== LEAK SUMMARY: 

==2326== definitely lost: 1 bytes in 1 blocks 

==2326== indirectly lost: 0 bytes in 0 blocks 

==2326== possibly lost: 0 bytes in 0 blocks 

==2326== still reachable: 352 bytes in 1 blocks 

==2326== suppressed: 0 bytes in 0 blocks 

==2326== Reachable blocks (those to which a pointer was found) are not shown. 
==2326== To see them rerun with: --leak-check=full --show-reachable=yes 
==2326== 

==2326== For counts of detected and suppressed errors, rerun with: -v 
==2326== Use --track-origins=yes to see where uninitialised values come from 
==2326== ERROR SUMMARY: 5 errors from 5 contexts (suppressed: 12 from 8) 











这 只 是 一 个 简单 的 示例 程序 ， 即 使 没有 valgrind， 我 们 也 可 以 很 轻易 地 发 现 问题 。 但 是 在 真实 的 项 
目 中 ， 当 代码 量 达到 万 行 、 十 万 行 甚至 百 万 行 时 ， 由 于 申请 的 内 存 可 能 不 是 在 一 个 地 方 被 使 用 ， 它 不 
可 避免 地 会 被 传 来 传 去 。 这 时 ， 如 果 只 是 靠 review 代 码 来 检查 问题 ， 可 能 很 难 找到 根本 原因 ， 而 使 用 
valgrind 则 可 以 很 容易 地 发 现 问题 所 在 。 























3.7 “长 跳 转 ”longjmp 








C 语 言 中 的 goto 语 句 由 于 可 以 直接 跳 转 到 函数 中 的 任意 一 行 ， 因 此 是 一 个 颇 受 争议 的 语句 。 有 人 认 
为 它 给 代码 带 来 了 混乱 ， 有 人 则 认为 适当 地 使 用 goto 语 句 可 以 让 代码 更 简洁 、 清 晰 一 一 比如 内 核 代码 中 
就 充斥 着 goto 语 句 的 使 用 。 关 于 这 点 ， 仁 者 见 仁 ， 智 者 见 智 吧 。 























goto 语 句 已 经 引发 了 这 么 大 的 争议 ， 而 C 库 还 提供 了 另外 一 组 接口 ， 用 于 实现 “长 跳 转 "”。 对 比 goto 
语句 只 能 在 函数 内 部 的 “ 短 跳 转 "”，longmp 可 以 实现 跨 函 数 的 “长 跳 转 ?。 下 面 我 们 来 详细 看 看 longmp 的 
使 用 方法 。 

















3.7.1 _ setimp 与 Jongjmp 的 使 用 


我 们 先 来 看 看 setjmp 的 代码 : 





#include <setjmp.h> 
int setjmp (jmp buf env); 
void longjmp (jmp buf env, int val); 





setimp 用 于 保存 当前 栈 的 上 下 文 ， 将 其 保存 到 参数 env 中 。 若 返回 0 值 ， 则 为 setimp 直 接 返 回 的 结 
果 ; 知 返 回 非 0 值 ， 则 为 从 longjmp 恢 复 栈 空 间 时 返回 的 结果 。 








longjmp 用 于 将 上 下 文 恢复 至 env 保 存 的 状态 ， 参 数 val 用 于 作为 恢复 点 setmp 的 返回 值 。 一 般 情况 
下 ， 保 存 的 jmp_bufenv 为 全 局 变量 。 跳 转 一 次 后 ， 保 存 的 env 上 下 文 环境 就 会 失效 。 请 看 下 面 的 示例 : 








#include <stdlib.h> 
#include <stdio.h> 
#include <setjmp.h> 
static jmp buf g stack env; 
static void funcl (void) ， 
static void func2 (void); 
int main (void) 
{ 
if (0 == setjmp(g stack env)) { 
printf ("Normal flow\n"); 
funcl();} else { 
printf ("Longjump flow\n"); 
} 


return 0; 





} 
static void funcl (void) 


{ 





printf ("Enter funcl\n"); 
fuNcG2() 


static void func2 (void) 

{ 
printf ("Enter func2\n"); 
longjmp(g_ stack env, 1); 
printf ("Leave func2\n"); 


} 





其 输出 结果 为 : 





Normal flow 
Enter funcl 
Enter func2 
Longjump flow 











在 main 函 数 中 ， 使 用 setimp 将 当前 的 栈 环 境 保存 到 g_ stack_ env 中 ， 然 后 调用 fanc1->func2， 在 fonc2 
中 ， 使 用 longjmp 来 恢复 保存 的 栈 环 境 g _ stack env， 从 而 完成 “长 跳 转 ”。 


3.7.2 “长 跳 转 ”的 实现 机 制 




















setimp 和 longjmp 分 别 用 于 保存 和 恢复 栈 的 上 下 文 ， 来 实现 长 跳 转 。 而 栈 的 实现 肯定 是 与 平台 相关 的 ， 因 此 setimp 和 1longjmp 的 实现 也 是 与 平 
台 相 关 的 。 

















先 看 一 下 structjmp_buf 的 定义 : 





/* Calling environment, plus possibly a saved signal mask. */ 
struct _ jmp buf tag 
{ 


/* NOTE: The machine-dependent definitions of `” sigsetjmp' 
assume that a ‘jmp buf' begins with a ’ jmp buf' and that . mask was saved' follows it. Do not move these members or add others before it. */ 
jmp buf jmpbuf; © /* Calling environment. */ 和 本 
Int mask was saved; /* Saved the signal mask? */ 
_ Sigset t _ saved mask; /* Saved signal mask. */ 
3 
typedef struct _ jmp buf tag jmp buf[1]; 








x86 平 台 的 ”jmp_buf 的 定义 为 : 





# if WORDSIZE == 64 

typedef long int _ jmp buf[8]; 

# elif defined x86 64 

typedef long long int _jmp buf[8]; 
# else 

typedef int jmp buf[6]; 

# endif ml 











UU 





x86 平 台 的 setjmp 和 longjmp 的 实现 均 位 于 glibc-2.17/sysdeps/i386/setjmp.S 中 。 





ENTRY (BP _ SYM (_ sigsetjmp)) 
ENTER 
/* 将 


jmpbuf 的 地 址 赋 给 


eax */ 
movl JMPBUF ($esp), geax 
CHECK_ BOUNDS BOTH WIDE ($eax, JMPBUF ($esp), $JB SIZE) 
/* 保存 寄存 器 


四 
/ 
movl Sebx, (JB BX*4) ($eax) 
movl Sesi, (JB SI*4) (S$eax) 
movl %edi, (JB DI*4) (Seax) 
leal JMPBUF ($esp), Secx /* Save SP as it will be after we return. */ 
#ifdef PTR MANGLE 
PTR MANGLE (%ecx) 
#endif 
movl %Secx, (JB SP*4) (Seax) 
movl PCOFF(Sesp), %ecx /* Save PC we are returning to now. */ 
LIBC PROBE (setjmp, 3, 4@%eax, -4@SIGMSK ($esp), 4@%ecx) 
#ifdef PTR MANGLE 
PTR MANGLE (Secx) 
#endifmovl %ecx, (JB PC*4) ($eax) 
LEAVE /* pop frame pointer to prepare for tail-call. */ 
mov1 %ebp, (JB BP*4) (%eax) /* Save caller's frame pointer. */ 
#if defined NOT IN libc && defined IS IN rtld 
/* In ld.so we never save the signal mask. */ 
xorl %eax, Seax 
ret 
#else 
/* Make a tail call to _sigjmp save; it takes the same args. */ 
jmp sigjmp save 
#endif 
END (BP_SYM (_ sigsetjmp)) 

















UD 


N 








上 面 的 汇编 代码 ， 主 要 是 将 寄存 器 EBX、ESI、EDI、ESP、PC 和 EBP 寄存 器 保存 到 jmp_bufy 
台 上 是 大 小 为 6 的 int 型 数组 ， 正 好 用 于 保存 这 6 个 寄存 器 。 

















。 回 想 前 面 _jmp_buf 的 定义 ， 它 在 x8632 位 平 









































@,. 细心 的 读者 会 发 现 这 里 的 汇编 是 _sigsetjmp 的 实现 ， 而 不 是 setjmp 的 实现 。 那 是 因为 在 glibc 库 中 ，setjmp 是 调用 sigsetjmp 来 
实现 的 。 














看 完了 _ sigsetjmp 的 实现 ， 自 然 就 轮 到 longjmp 了 : 





ENTRY (__longjmp) 
movl 4(%Sesp), Secx /* User's jmp buf in %ecx. */ 
movl 8(%esp), Seax /* Second argument is return value. */ 
/* Save the return address now. */ 
movl (JB PC*4) ($ecx), Sedx 
LIBC PROBE (longjmp, 3, 4Q@%ecx, -4@%eax, 4@%edx) 
/* 恢复 保存 的 寄存 器 


二 
movl (JB BX*4) 
mov1 (JB SI*4) 
movl (JB DI*4) ($ecx), Sedi 
movl (JB BP*4) ($ecx), $ebp 
movl (JB SP*4) (Secx), %esp 
LIBC PROBE (longjmp target, 3, 4@%ecx, -4@%ecx, 4@%edx) 
/* Jump to saved PC. */ 
jmp *%Sedx 
END (__ longjmp) 


Secx), gebx 
Secx), Sesi 





setjmp 保 存 寄存 器 的 内 容 ，longjmp 自 然 是 恢复 寄存 器 的 内 容 。 上 面 的 代码 很 简单 ， 把 寄存 器 PC、EBX、ESI、EDI、EBP 和 ESP 的 内 容 恢复 
后 ， 将 第 二 个 参数 val 保 存 到 EAX 中 ， 最 后 跳 转 到 恢复 的 PC 寄存 器 处 一 一 也 就 是 setjmp 的 下 一 条 指令 的 位 置 。 


















































3.7.3 “长 跳 转 ”的 陷阱 





从 3.7.2 节 对 setimp 和 longjmp 实 现 的 分 析 中 ， 我 们 可 以 发 现 ，setimp 和 longjmp 的 实现 原理 就 是 对 与 栈 
相关 的 寄存 器 的 保存 与 恢复 。 那 么 ， 变 量 的 情况 又 是 什么 样 的 呢 ? 对 于 全 局 变量 和 static 变 量 来 说 ， 由 
于 它们 都 不 是 保存 在 栈 上 的 ， 所 以 在 longjmp 跳 转 后 ， 其 值 不 会 改变 。 局 部 变量 的 情况 又 如 何 呢 ? 





longjmp 的 man 手 册 给 出 了 如 下 说 明 : 





当 满 足以 下 条 件 时 ， 局 部 变量 的 值 是 不 能 确定 的 : 





.它们 是 调用 setmp 所 在 函数 的 局 部 变量 。 
其 值 在 setjmp 和 longjmp 之 间 有 变化 。 
:它们 没有 被 声明 为 volatile 变 量 。 


我 们 来 做 一 个 试验 : 





#include <stdlib.h> 

#include <stdio.h> 

#include <setjmp.h> 

static jmp buf g stack env; 

static void funcl (int *a, int *b, int *o); 
int main (voidgd) 


{ 


int a = 1; 
int b = 2; 
nt jC: S33 
int ret = setjmp(g stack env); 


if (0 == ret) { 
printf ("Normal flow\n"); 
printf("a = $d, b = %d, c = %d\n", a, b, c); 
funcl(&a, &b, &c); 
} else { 
printf ("Longjump flow\n"); 
printf("a = $d, b = %d, c = %d\n", a, b, c);} 
return 0; 





} 
static void funcl (int *a, int *b, int *c) 
{ 
printf ("Enter funcl\n"); 
++ (*a); 
二 二 (SID) 
十 十 (二 G) > 
printf("funcl: a = %d, b = %d, c = %d\n", *a, xb xc) 7 
longjmp(g stack env, 1); 
printf ("Leave funcl\n"); 





[fgao@ubuntu chapter3]#gcc 4 7 3 longjmp var.c -Wall 
[fgao@ubuntu chapter3]#./a.out 

Normal flow 

a=1,b=2, c=3 

Enter funcl 

funcl: a=2, b=3, c= 4 

Longjump flow 

a=2,b=3,c=4 

















从 结果 上 看 ， 变 量 a、b、<c 的 值 均 没有 被 恢复 。 这 点 符合 我 们 的 预期 ， 毕 竟 longjmp 只 是 恢复 了 6 个 


寄存 器 的 内 容 。 
然而 当 我 们 加 上 编译 选项 -02 以 后 ， 结 果 就 完全 不 同 了 。 


[fgao@ubuntu chapter3]#gcc 4 7 3 longjmp var.c -Wall -02 
[fgao@ubuntu chapter3]#./a.out 

Normal flow 

a=1,b=2,c=3 

Enter funcl 

funcl: a=2, b=3, c= 4 

Longjump flow 

a=1,b=2,c=3 





在 longjmp 跳 转 以 后 ，a、b 和 c 的 值 仍然 是 原来 的 值 。 











除了 上 面 这 个 缺陷 以 外 ， 如 果 我 们 的 思维 再 开阔 些 ， 还 能 发 现 由 longjmp 实 现 原理 引发 的 其 他 缺 
陷 。 比 如 因为 它 不 能 处 理 局 部 变量 的 问题 ， 因 此 在 C++ 中 局 部 变量 的 析 构 肯定 也 是 有 问题 的 。 




















请 看 下 面 的 示例 : 


#include <setjmp.h> 
#include <iostream> 
using namespace std; 
static jmp buf g stack env; 
statle -volid funcl(vold) 
class Test { 
Publie: 

Test() { 

cout << "Constructor" << endl; 





} 
~Test() { 
cout << "Destructor" << endl; 
} 
}; 
int main (void) 
{ 
int ret = setjmpl(g stack env); 
if (0 == ret) { 
cout << "Normal flow" << endl; 
CI) 
} else { 
cout << "Longjump flow" << endl; 
} 





其 输出 结果 为 : 


[fgao@ubuntu chapter3]#g++ 4 7 3 longjmp destructor.cpp -Wall 
[fgao@ubuntu chapter3]#./a.out 

Normal flow 

Enter funcl 

Constructor 

Longjump flow 





之 所 以 Test 的 析 构 函数 没有 被 调用 ， 是 因为 longjmp 是 glibc 库 中 的 函数 ， 它 直接 恢复 了 栈 的 上 下 
文 ， 因 此 程序 不 会 调用 Test 的 析 构 函数 。 


第 4 章 ”进程 控制 进程 的 一 生 





进程 是 操作 系统 的 一 个 核心 概念 。 每 个 进程 都 有 自己 唯一 的 标识 : 进程 D， 也 有 自己 的 生命 周 
期 。 一 个 典型 的 进程 的 生命 周期 如 图 4-1 所 示 。 

















图 4-1 进程 的 生命 周期 


本 章 将 会 介绍 进程 ID、 进 程 的 层次 ， 以 及 进程 生命 周期 内 的 各 个 阶段 。 





4.1 进程 DD 


Linux 下 每 个 进程 都 会 有 一 个 非 负 整数 表示 的 唯一 进程 ID， 简 称 pid。Linux 提 供 了 getpid 函 数 来 获取 





进程 的 pid， 同 时 还 提供 了 getppid 函 





#include <sys/types.h> 
#include <unistd.h> 
pid t getpid(voidqd); 
pid t getppid(void); 








数 来 获取 父 进 程 的 pid， 相 关 接 口 定 义 如 下 : 





每 个 进程 都 有 自己 的 父 进程 ， 











-> 


父 进程 又 会 有 自己 的 父 进程 ， 最 终 都 会 追溯 到 1 号 进程 即 init 进 程 。 这 
人 


就 决定 了 操作 系统 上 所 有 的 进程 必然 会 组 成 树 状 结构 ， 就 像 一 个 家 族 的 家 谱 一 样 。 可 以 通过 pstree 的 命 





令 来 查看 进程 的 家 族 树 。 








procfs 文 件 系 统 会 在 /proc 下 为 每 个 进程 创建 一 个 目录 ， 名 字 是 该 进程 的 pid。 目 录 下 有 很 多 文件 ， 
用 于 记录 进程 的 运行 情况 和 统计 信息 等 ， 如 下 所 示 : 




















]1] /proc 总 用 量 


dr—xr-xr-x 9 rookt root 
1 :0656-1 

dr-xr-xXr-x 9 root root 
1 06:56 :10 

dr-xr-xr-x 9 root root 
1 0Q6:56 :100 

dr-xr-Xr-xX 9 root root 
1 06:56 101 

dr-xr-xXr-x 9 root root 
1 O656: TL02 

dr-xr-Xr-x 9 root root 
1 06:56 103 

dr-xr-xr-x 9 root root 


1 0Q6:56 1039 
dr-xr-Xr-X 9 root root 


1 06:56 104 





0 4 月 
0 4 月 
0 4 月 
0 4 月 
0 4 月 
0 4 月 
0 4 月 
0 4 月 





因为 进程 有 创建 ， 也 有 终止 ， 所 以 /proc/ 下 记录 进程 信息 的 目录 (以 及 目录 下 的 文件 ) 也 会 发 生变 





化 。 














操作 系统 必须 保证 在 任意 时 刻 都 不 能 出 现 两 个 进程 有 相同 pid 的 情况 。 虽 然 进程 ID 是 唯一 的 ， 但 是 
进程 ID 可 以 重用 。 进 程 退 出 以 后 ， 其 进程 ID 还 可 以 再 次 分 配给 其 他 的 进程 使 用 。 那 么 问题 就 来 了 ， 内 
核 是 如 何 分 配 进程 ID 的 ? 























Linux 分 配 进程 ID 的 算法 不 同 于 给 进程 分 配 文件 描述 符 的 最 小 可 用 算法 ， 它 采用 了 延迟 重用 的 算 











法 ， 即 分 配给 新 创建 进程 的 ID 尽量 不 与 最 近 终止 进程 的 ID 重复 ， 这 样 就 可 以 防止 将 新 创建 的 进程 误 判 














为 使 用 相同 进程 ID 的 已 经 退出 的 进程 。 


那么 如 何 实现 延迟 重用 呢 ? 内 核 采 用 的 方法 如 下 : 





1) 位 图 记录 进程 ID 的 分 配 情况 (0 为 可 用 ，1 为 已 占用 ) 。 








2) 将 上 次 分 配 的 进程 ID 记 录 到 last_pid 中 ， 分 配 进 程 ID 时 ， 从 last_pid+1 开 始 找 起 ， 从 位 图 中 寻找 


可 用 的 ID。 


3) 如 果 找 到 位 图 


既然 是 位 图 








集合 的 最 后 一 位 仍 不 可 用 ， 则 回 滚 到 位 图 集合 的 起 始 位 置 ， 从 头 开始 找 。 











记录 进程 也 的 分 配 情况 ， 那 么 位 图 的 大 小 就 必须 要 考虑 周全 。 位 图 的 大 小 直接 决定 了 

















系统 允许 同时 存在 的 进程 的 最 大 个 数 ， 这 个 最 大 个 数 在 系统 中 称 为 pid_max。 


上 面 的 第 3 步 提 到 ， 回 











种 说 法 并 不 正确 





有， 回 ] 








绕 到 位 图 集合 的 起 始 位 置 ， 从 头 寻 找 可 用 的 进程 DD。 事 实 上 ， 严 格 说 来 ， 这 








绕 时 并 不 是 从 0 开始 找 起 ， 而 是 从 300 开 始 找 起 。 内 核 在 kernel/pid.c 文 件 中 定义 了 





RESERVED PIDS， 其 值 是 300，300 以 下 的 pid 会 被 系统 占用 ， 而 不 能 分 配给 用 户 进 程 : 


define RESERVED PIDS 
int pid max = PID MAX DEFAULT; 


Linux 系 统 下 可 以 通过 procfs 或 sysctl 命 令 来 查看 pid max 的 值 : 


300 





manu@manu-rush:~$ cat /proc/sys/kernel/pid max 


131072 


manu@manu-rush:~$ sysctl kernel.pid max 
kernel.pid max = 131072 


其 实 ， 此 上 限 值 是 可 以 调整 的 ， 系 统管 理 员 可 以 通过 如 下 方法 来 修改 此 上 限 值 : 














root@manu-rush:~# sysctl -WwW kernel.pid max=4194304 
kernel .pid max = 4194304 


但 是 内 核 自己 也 设置 了 硬 上 限 ， 如 果 尝 试 将 pid_max 的 值 设 成 一 个 大 于 硬 上 限 的 值 就 会 失败 ， 如 下 
所 示 : 








root@manu-rush:~# sysctl -~-w kernel.pid max=4194305 
error: "Invalid argument" setting key "kernel.pid max" 


从 上 面 的 操作 可 以 看 出 ，Linux 系 统 将 系统 进程 数 的 硬 上 限 设置 为 4194304(4M) 。 内 核 又 是 如 何 
决定 系统 进程 个 数 的 硬 上 限 的 呢 ? 对 此 ， 内 核定 义 了 如 下 的 宏 : 











define PID MAX LIMIT (CONFIG BASE SMALL ? PAGE SIZE * 8 : \ 
(sizeof(long) > 4 ? 4 * 1024 * 1024 :PID MAX DEFAULT)) 








从 上 面 代码 中 可 以 看 出 决定 系统 进程 个 数 硬 上 限 的 逻辑 为 : 

















:如果 选择 了 CONFIG _ BASE SMALL 编译 选项 ， 则 为 页 面 (PAGE _SIZE) 的 位 数 。 





:如 果 选 择 了 CONFIG BASE FULL 编 译 选项 ， 那 么 : 











:对 于 32 位 系统 ， 系 统 进程 个 数 硬 上 限 为 32768 ( 即 32K) 。 





.对 于 64 位 系统 ， 系 统 进程 个 数 硬 上 限 为 4194304 〈 即 4M) 。 


通过 上 面 的 讨论 可 以 看 出 ， 在 64 位 系统 中 ， 系 统 容许 创建 的 进程 的 个 数 超过 了 400 万 ， 这 个 数字 是 
相当 庞大 的 ， 足 够 应 用 层 使 用 。 




















对 于 单线 程 的 程序 ， 进 程 卫 比 较 好 理解 ， 就 是 唯一 标识 进程 的 数字 。 对 于 多 线程 的 程序 ， 每 一 个 
线程 调用 getpid 函 数 ， 其 返回 值 都 是 一 样 的 ， 即 进程 的 ID。 








4.2 ”进程 的 层次 








每 个 进程 都 有 父 进 程 ， 父 进程 也 有 父 进程 ， 这 就 形成 了 一 个 以 init 进 程 为 根 的 家 族 树 。 除 此 以 外 ， 
进程 还 有 其 他 层次 关系 : 进程 、 进 程 组 和 会 话 。 

















进程 组 和 会 话 在 进程 之 间 形 成 了 两 级 的 层次 : 进程 组 是 一 组 相关 进程 的 集合 ， 会 话 是 一 组 相关 进 
时 组 的 集合 。 用 人 来 打 比 方 ， 会 话 如 同一 个 公司 ， 进 程 组 如 同 公司 里 的 部 门 ， 进 程 则 如 同 部 门 里 的 员 
工 。 尽 管 每 个 员工 都 有 父亲 ， 但 是 不 影响 员工 同时 属于 某 个 公司 中 的 某 个 部 门 。 





























这 样 说 来 ， 一 个 进程 会 有 如 下 ID: 














:PID: 进程 的 唯一 标识 。 对 于 多 线程 的 进程 而 言 ， 所 有 线程 调用 getpid 函 数 会 返回 相同 的 值 。 





-PGID: 进程 组 ID。 每 个 进程 都 会 有 进程 组 ID， 表 示 该 进程 所 属 的 进程 组 。 默 认 情 况 下 新 创建 的 进 
程 会 继承 父 进程 的 进程 组 ID。 

















“SID: 会 话 ID。 每 个 进程 也 都 有 会 话 ID。 默 认 情 况 下 ， 新 创建 的 进程 会 继承 父 进程 的 会 话 ID。 











可 以 调用 如 下 指令 来 查看 所 有 进程 的 层次 关系 : 





ps -ejH 
ps axjf 











对 于 进程 而 言 ， 可 以 通过 如 下 函数 调用 来 获取 其 进程 组 ID 和 会 话 ID。 





#include <unistd.h> 
pid t getpgrp (void); 
pid t getsid(pid t piqgd); 





前 面 提 到 过 ， 新 进程 默认 继承 父 进程 的 进程 组 ID 和 会 话 ID， 如 果 都 是 默认 情况 的 话 ， 那 么 追根 漳 
源 可 知 ， 所 有 的 进程 应 该 有 共同 的 进程 组 ID 和 会 话 ID。 但 是 调用 ps axj{ 可 以 看 到 ， 实 际 情况 并 非 如 此 ， 
系统 中 存在 很 多 不 同 的 会 话 ， 每 个 会 话 下 也 有 不 同 的 进程 组 。 




















为 何 会 如 此 呢 ? 








就 像 家 族 企 业 一 样 ， 如 果 从 创业 之 初 ， 所 有 家 族 成 员 都 墨守成规 ， 循 规 蹈 矩 ， 默 认 情 况 下 ， 就 只 
会 有 一 个 公司 、 一 个 部 门 。 但 是 也 有 些 “ 叛 逆 ” 的 子弟 ， 愿 意 为 家 族 公司 开 疆 拓 土 ， 愿 意 成 立新 的 部 
门 。 这 些 新 的 部 门 就 是 新 创建 的 进程 组 。 如 果 有 子弟 “ 离 经 叛 道 ”， 甚 至 不 愿意 采 在 家 族 公司 里 ， 他 别 
开 天 地 ， 男 创 了 一 个 公司 ， 那 这 个 新 公司 就 是 新 创建 的 会 话 组 。 由 此 可 见 ， 系 统 必须 要 有 改变 和 设置 
进程 组 ID 和 会 话 ID 的 函数 接口 ， 人 否则， 系统 中 只 会 存在 一 个 会 话 、 一 个 进程 组 。 
































制 而 引入 的 概念 。 


进程 组 和 会 话 是 为 了 文 持 shell 作 汪 控 人 
当 有 新 的 用 户 登 录 Linux 时 ， 登 录 进 程 会 为 这 个 用 户 创建 一 个 会 话 。 用 户 的 登录 shell 就 是 会 话 的 首 


进程 。 会 话 的 首 进 程 ID 会 作为 整个 会 话 的 太 。 会 话 是 一 个 或 多 个 进程 组 的 集合 ， 训 括 了 登录 用 户 的 所 























有 活动 。 
警 道 ， 让 多 个 进程 互相 配合 完成 一 项 工作 ， 这 一 组 进程 属于 同一 





能 会 使 用 管 








青 景 是 类 似 的 。 


在 登录 shell 时 ， 用 户 可 


个 进程 组 。 
当 用 户 通 过 SSH 客 户 端 工具 (putty、xshell 等 ) 连 入 Linux 时 ， 与 上 述 登 录 的 和 


4.2.1 进程 组 


修改 进程 组 ID 的 接口 如 下 : 


#include <unistd.h> 
int setpgid(piqd t pidq，Ppid t pgiqd); 


这 个 函数 的 含义 是 ， 找 到 进程 DD 为 pid 的 进程 ， 将 其 进程 组 DD 修改 为 pgid， 如 果 pid 的 值 为 0%， 则 表 
示 要 修改 调用 进程 的 进程 组 ID。 该 接口 一 般 用 来 创建 一 个 新 的 进程 组 。 




















下 面 三 个 接口 含义 一 致 ， 都 是 创立 新 的 进程 组 ， 并 且 指 定 的 进程 会 成 为 进程 组 的 首 进程 。 如 果 参 
数 pid 和 pgid 的 值 不 匹配 ， 那 么 setpgid 函 数 会 将 一 个 进程 从 原来 所 属 的 进程 组 迁移 到 pgid 对 应 的 进程 组 。 





























setpgid(0,0) 
setpgid(getpid(),0) 
setpgiq(getpid() ,getpidqd() ) 


setpgid 函 数 有 很 多 限制 ; 





SR 


pid 参数 必 须 指定 为 调用 setpgid 函 数 的 进程 或 其 子 进 程 ， 不 能 随意 修改 不 相关 进程 的 进程 组 ID， 如 
果 违 反 这 条 规则 ， 则 返回 -1， 并 置 errno 为 ESRCH。 














.pid 参 数 可 以 指定 调用 进程 的 子 进程 ， 但 是 子 进程 如 果 已 经 执行 了 exec 函 数 ， 则 不 能 修改 子 进程 的 
进程 组 D。 如 果 违 反 这 条 规则 ， 则 返回 -1， 并 置 errno 为 EACCESS 。 

















.在 进程 组 间 移 动 ， 调 用 进程 ，pid 指 定 的 进程 及 目标 进程 组 必须 在 同一 个 会 话 之 内 。 这 个 比较 好 理 
解 ， 不 加 入 公司 〈 会 话 ) ， 就 无 法 加 入 公司 下 属 的 部 门 〈 进 程 组 ) ， 和 否则 就 是 部 门 要 造反 的 节奏 。 如 
果 违 反 这 条 规则 ， 则 返回 -1， 并 置 errno 为 EPERM。 


























-pid 指定 的 进程 ， 不 能 是 会 话 首 进程 。 如 果 违 反 这 条 规则 ， 则 返回 -1， 并 置 errno 为 EPERM。 








有 了 创建 进程 组 的 接口 ， 新 创建 的 进程 组 就 不 必 继 承 父 进程 的 进程 组 ID 了 。 最 常见 的 创建 进程 组 
的 场景 就 是 在 shell 中 执行 管道 命令 ， 代 码 如 下 : 























cmdl | cmd2 | cmd3 


下 面 用 一 个 最 简单 的 命令 来 说 明 ， 其 进程 之 间 的 关系 如 图 4-2 所 示 。 





ps ax|grep nfsd 


程 组 


的 路 
样 。 





fork & exec fork & exec 


grep nfsd 
4694 


PGID 4693 





八 _ 少 表示 进程 组 组 长 


图 4-2 ”进程 组 和 进程 的 关系 








ps 进程 和 grep 进 程 都 是 bash 创 建 的 子 进程 ， 两 者 通过 管道 协同 完成 一 项 工作 ， 它 们 隶属 于 同一 个 进 


， 其 中 ps 进程 是 进程 组 的 组 长 。 








进程 组 的 概念 并 不 难 理解 ， 可 以 将 人 与 人 之 间 的 关系 做 类 比 。 一 起 工作 的 同事 ， 自 然 比 训 不 相干 
人 更 加 亲近 。shell 中 协同 工作 的 进程 属于 同一 个 进程 组 ， 就 如 同 协同 工作 的 人 属于 同一 个 部 门 





























引入 了 进程 组 的 概念 ， 可 以 更 方便 地 管理 这 一 组 进程 了 。 比 如 这 项 工作 放弃 了 ， 不 必 向 每 个 进程 
发 送信 号 ， 可 以 直接 将 信号 发 送 给 进程 组 ， 进 程 组 内 的 所 有 进程 都 会 收 到 该 信和 号 














前 文 曾 提 到 过 ， 子 进程 一 旦 执行 exec， 父 进程 就 无 法 调用 setpgid 函 数 来 设置 子 进程 的 进程 组 JD 了， 
规则 会 影响 shell 的 作业 控制 。 出 于 保险 的 考虑 ， 一 般 父 进程 在 调用 fork 创 建 子 进程 后 ， 会 调用 

















setpgid 函 数 设置 子 进 程 的 进程 组 ID， 同 时 子 进 程 也 要 调用 setpgid 函 数 来 设置 自身 的 进程 组 ID。 这 两 次 调 


用 有 一 


进入 


成 在 一 








次 是 多 余 的 ， 但 是 这 样 做 能 够 保证 无 论 是 父 进程 先 执行 ， 还 是 子 进程 先 执行 ， 子 进程 一 定 已 经 
了 指定 的 进程 组 中 。 由 于 fork 之 后 ， 父 子 进程 的 执行 顺序 是 不 确定 的 ， 因 此 如 果 不 这 样 做 ， 就 会 造 
定 的 时 间 窗 口内 ， 无 法 确定 子 进程 是 否 进 入 了 相应 的 进程 组 。 






































可 以 通过 跟踪 bash 进 程 的 系统 调用 来 证 明 这 一 点 ， 下 面 的 2258 进 程 是 bash， 我 们 在 该 bash 上 执行 











sleep 200， 在 执行 之 前 ， 在 另 一 个 终端 用 strace 跟 踪 bash 的 系统 调用 ， 可 以 看 到 ， 父 进程 和 子 进 程 都 执 


行 了 一 


裔 setpgid 函 数 ， 代 码 如 下 所 示 : 


manu@manu-hacks:~$ sudo strace -f -p 2258 
Process 2258 attached 











/* 父 进程 调用 








Setpgig 函 数 


大 


[pid 2258] setpgid(2509, 2509 <unfinished ...>... 


/* 子 进程 调用 


Setpgid 函 数 


«7 


[Eid 2509] ‘setpgid(2509,; 2509 <unfinished .> 


/* 子 进程 执行 


execve*/ 


[pid 2509] execve("/bin/sleep", ["sleep", "200"], [/* 31 vars */]) 



































用 户 在 shell 中 可 以 同时 执行 多 个 命令 。 对 于 耗 时 很 久 的 命令 〔 如 编译 大 型 工程 》， 用 户 不 必 傻 作 
等 待命 令 运行 完毕 才 执行 下 一 个 命令 。 用 户 在 执行 命令 时 ， 可 以 在 命令 的 结尾 添加 “&”" 符 号 ， 表 示 将 命 
令 放 入 后 台 执行 。 这 样 该 命令 对 应 的 进程 组 即 为 后 台 进 程 组 。 在 任意 时 刻 ， 可 能 同时 存在 多 个 后 台 进 
程 组 ， 但 是 不 管 什么 时 候 都 只 能 有 一 个 前 台 进 程 组 。 只 有 在 前 台 进 程 组 中 进程 才能 在 控制 终端 读 取 输 
入 。 当 用 户 在 终端 输入 信号 生成 终端 字符 〈 如 ctrl+tc、ctrl+tz、ctrh 等 ) 时 ， 对 应 的 信号 只 会 发 送 给 前 台 
进程 组 。 

shell 中 可 以 存在 多 个 进程 组 ， 无 论 是 前 台 进 程 组 还 是 后 台 进 程 组 ， 它 们 或 多 或 少 存在 一 定 的 联 











系 ， 为 了 更 好 地 控制 这 些 进 程 组 〈 或 者 条 
的 工作 吉 括 在 一 个 终 
台 执 行 。 


尔 为 作业 ) ， 系 统 引 入 了 会 


终端 ， 选 取 其 中 一 个 作为 前 台 来 直接 接收 终端 的 输入 及 信号， 


话 的 概念 。 会 话 的 意义 在 于 将 很 多 
其 他 的 工作 则 放 在 后 





4.2.2 会话 


会 话 是 一 个 或 多 个 进程 组 的 集合 ， 以 用 户 登 录 系 统 为 例 ， 可 能 存在 如 图 4-3 所 示 的 情况 。 








图 4-3 ”进程 组 与 会 话 的 关系 


系统 提供 setsid 函 数 来 创建 会 话 ， 其 接口 定义 如 下 : 








#include <unistd.h> 
pid t setsid(void); 





如 果 这 个 函数 的 调用 进程 不 是 进程 组 组 长 ， 那 么 调用 该 函数 会 发 生 以 下 事情 : 





1) 创建 一 个 新 会 话 ， 会 话 ID 等 于 进程 ID， 调 用 进程 成 为 会 话 的 首 进程 。 











2) 创建 一 个 进程 组 ， 进 程 组 ID 等 于 进程 ID， 调 用 进程 成 为 进程 组 的 组 长 。 











3) 该 进程 没有 控制 终端 ， 如 果 调 用 setsid 前 ， 该 进程 有 控制 终端 ， 这 种 联系 就 会 断 掉 。 





调用 setsid 函 数 的 进程 不 能 是 进程 组 的 组 长 ， 否 则 调用 会 失败 ， 返 回 -1， 并 置 errno 为 EPERM。 


这 个 限制 是 比较 合理 的 。 如 果 人 允许 进程 组 组 长 迁移 到 新 的 会 话 ， 而 进程 组 的 其 他 成 员 仍然 在 老 的 
会 话 中 ， 那 么 ， 就 会 出 现 同一 个 进程 组 的 进程 分 属 不 同 的 会 话 之 中 的 情况 ， 这 就 破坏 了 进程 组 和 会 话 
的 严格 的 层次 关系 了 。 











Linux 提 供 了 setsid 命 令 ， 可 以 在 新 的 会 话 中 执行 命令 ， 通 过 该 命令 可 以 很 容易 地 验证 上 面 提 到 的 三 








manu@manu-hacks:~$ setsid sleep 100 
manu@manu-hacks:~$ ps ajxf 


PPLD PID PGID SLID TIY TPGID STAT UID TIME COMMAND... 


. 4469 4469 4469 ? = SS 1000 0:00 sleep 100 











从 输出 中 可 以 看 出 ， 系 统 创建 了 新 的 会 话 4469， 新 的 会 话 下 又 创建 了 新 的 进程 组 ， 会 话 ID 和 进程 
组 ID 都 等 于 进程 ID， 而 该 进程 已 经 不 再 拥有 任何 控制 终端 了 〈TTY 对 应 的 值 为 "? “表示 进程 没有 控制 余 

















端 ) 。 








常用 的 调用 setsid 函 数 的 场景 是 login 和 shell。 除 此 以 外 创建 daemon 进 程 也 要 调用 setsid 函 数 。 





4.3 进程 的 创建 之 fork () 









































Linux 系 统 下 ， 进 程 可 以 调用 fork 函 数 来 创建 新 的 进程 。 调 用 进程 为 父 进程 ， 被 创建 的 进程 为 子 进程 。 

















fork 函 数 的 接口 定义 如 下 ; 








#include <unistd.h> 
pid t fork(void); 





















































与 普通 函数 不 同 ，fork 函 数 会 返回 两 次 。 一 般 说 来 ， 创 建 两 个 完全 相同 的 进程 并 没有 太 多 的 价值 。 大 部 分 情况 下 ， 父 子 进程 会 执行 不 同 的 代 
码 分 支 。fork 函 数 的 返回 值 就 成 了 区 分 父子 进程 的 关键 。fork 函 数 向 子 进程 返回 9， 并 将 子 进程 的 进程 ID 返 给 父 进 程 。 当 然 了 ， 如 果 f0tk 失 败 ， 该 


函数 则 返回 -1， 并 设置 errno。 





































































































常见 的 出 错 情景 如 表 4-1 所 示 。 
表 4-1 ”fork 函数 可 能 的 errno 
errno 说 明 
EAGAIN 超出 了 用 户 容许 创建 的 进程 上 限 ， 也 可 能 是 超出 了 系统 容许 的 进程 个 数 的 上 限 
ENOMEM 无 法 分 配 相应 的 内 核 结 构 ， 内 存 紧 张 的 情况 下 ， 可 能 发 生 该 错误 
ENOSYS 平台 不 支持 fork 


所 以 一 般 而 言 ， 调 用 fork 的 程序 ， 大 多 会 如 此 处 理 : 





ret = fork() 7 
if(ret == 0) 
{ 


/ /此 处 是 子 进 程 的 代码 分 支 
3 

else if(ret > 0) 
{ 

/ /此 处 是 父 进程 的 代码 分 支 
Sloe 


// fork 失 败 ， 执 行 


error handle 



































© 注意 fork 可 能 失败 。 检 查 返回 值 进行 正确 的 出 错 处 理 ， 是 一 个 非常 重要 的 习惯 。 设 想 如 果 fork 返 回 -1， 而 程序 没有 判断 返回 值 ， 
接 将 -1 当成 子 进程 的 进程 号 ， 那 么 后 面 的 代码 执行 kill] (child_pid，9) 就 相当 于 执行 kill (-1，9) 。 这 会 发 生 什 么 ? 后 果 是 惨重 的 ， 它 将 杀 死 除 
了 init 以 外 的 所 有 进程 ， 只 要 它 有 权限 。 读 者 可 以 通过 man 2 kill 来 查看 kill (-1，9) 的 含义 。 





































































































fork 之 后 ， 对 于 父子 进程 ， 谁 先 获得 CPU 资源 ， 而 率先 运行 呢 ? 





























从 内 核 2.6.32 开 始 ， 在 默认 情况 下 ， 父 进程 将 成 为 fork 之 后 优先 调度 的 对 象 。 采 取 这 种 策略 的 原因 是 : fork 之 后 ， 父 进程 在 CPU 中 处 于 活跃 的 
状态 ， 其 内 存 管 理 信 息 也 被 置 于 硬件 内 在 管理 单元 的 转译 后 备 缓冲 器 〈TLB) ， 所 以 先 调度 父 进程 能 提升 性 能 。 



















































































从 2.6.24 起 ，Linux 采 用 完全 公平 调度 (Completely Fair Scheduler，CFS) 。 用 户 创建 的 普通 进程 ， 都 采用 CFS 调 度 策略 。 对 于 CFS 调 度 策 
略 ，procfs 提 供 了 如 下 控制 选项 : 
































/proc/sys/Kkernel/sched child runs first 















































该 值 默认 是 0， 表 示 父 进程 优先 获得 调度 。 如 果 将 该 值 改 成 1， 那 么 子 进程 会 优先 获得 调度 。 





















































POSIX 标 准 和 Linux 都 没有 保证 会 优先 调度 父 进 程 。 因 此 在 应 用 中 ， 决 不 能 对 父子 进程 的 执行 顺序 做 任何 的 假设 。 如 果 确 实 需要 某 一 特定 执 
行 的 顺序 ， 那 么 需要 使 用 进程 间 同 步 的 手段 。 






























































4.3.1 


fork 之 后 的 子 进程 完全 











存 关系 : 


fork 之 后 父子 进程 的 内 存 关 系 























拷贝 了 父 进 程 的 地 址 空间 ， 包 括 栈 、 堆 、 代 码 段 等 。 通 过 下 面 的 示例 代码 ， 我 们 一 起 来 查看 父子 进 





程 的 内 





# 
# 
# 
# 
# 
# 


include <stdio.h> 
include <stdlib.h> 
include <unistd.h> 
include <string.h> 
include <errno.h> 
include <sys/types.nh 


#include <wait.h> 
int og .int = 12 
int main() 


{ 


int local int = 1 


> 


7 


int *malloc int = malloc (sizeof (int)); 


和 六] loo. 4nt = 1 
pid t pid = fork( 


和 


if (piqd == 0) /* 子 进程 


5 


10ca1 int = { 
int = 0 


7 


*malloc int = 0; 


fprintf(stderr,"[CHILD ] child change local global malloc value to 0\n"); 


free (malloc i 
Sleep (10); 


nt); 


fprintf (stderr,"[CHILD ] child exit\n"); 


exit (0); 


} 
else if(pid < 0) 


printf ("fork failed ($s)",strerror(errno)); 


return 1; 


} 


fprintf (stderr,"[PARENT] wait child exit\n"); 


waitpid (pigd, NULL, 


0); 


fprintf (stderr,"[PARENT] child have exit\n"); 
printf ("[PARENT] g int = %d\n",g int); 
printf("[PARENT] local int = $d\n",local int); 
printf ("[PARENT] malloc int = %d\n",local int); 


free (malloc int); 
return 0; 



































这 里 刻意 定义 了 三 个 变量 ， 











个 是 位 于 数据 段 的 全 局 变量 ， 一 个 是 位 于 栈 上 的 局 部 变量 ， 还 有 






































上 的 变量 ， 三 者 的 初始 值 都 是 1。 然 后 调用 fork 创 建 子 进程 ， 子 进程 将 三 个 变量 的 值 都 改 成 了 0。 


按照 fork 的 语义 ， 
































子 进程 
并 行 不 悼 、 互 不 影响 的 。 医 














此 ， 在 上 面 示例 代码 中 ， 尽 管子 进 








{TT 
































然 是 1， 代 码 的 输出 也 证 实 了 这 一 点 。 





个 是 通过 malloc 动 态 分 配 位 了 








上 堆 














呈 鄙 三 | 





完全 拷贝 了 父 进程 的 数据 段 、 栈 和 堆 上 的 内 存 ， 如 果 父子 进程 对 相应 的 数据 进行 修改 ， 那 么 两 个 进程 是 
程 将 三 个 变量 的 值 都 改 成 了 0， 对 父 进程 而 言 这 三 个 值 都 没有 变化 ， 仍 
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[PARENT 


wait child exit 
child change local global malloc value to 0 


child have exit 


ll 


malloe dnt 1 





提供 了 exec 系 列 函数 。 这 




















前 文 提 到 过 ， 子 进程 和 父 进程 

















个 系列 函数 会 丢弃 现存 的 程序 代码 段 ， 并 构建 新 的 数据 段 、 栈 及 堆 。 调 


exec 系 列 函数 ， 来 执行 新 的 程序 。 























在 这 种 背景 下 ，fork 时 子 进程 完全 
































执行 一 模 一 样 的 代码 的 情形 比较 少见 。Linux 提 供 了 execve 系 统 调用 ， 构 建 在 该 系统 调用 之 上 ，glibc 



























































刚刚 辛苦 拷贝 的 内 存 。 为 了 解决 这 个 问题 ，Linux 引 入 了 写 时 拷贝 (copy-on-write〉 的 技术 。 


只 读 〈 如 图 
尝试 修改 ， 就 会 引发 缺 页 异 





| 











站 








写 时 找 贝 是 指 子 进程 的 页 表 项 指向 与 父 进 程 相同 的 物理 内 存 页 ， 这 样 只 拷贝 父 进程 的 页 表 项 就 可 以 了 ， 当 然 要 把 这 些 页 面 
4-4 所 示 ) 。 如 果 父子 进程 都 不 修改 内 存 的 内 容 ， 大 家 便 相 安 无 事 ， 共 用 一 份 物理 内 存 页 。 但 是 一 旦 父 





FPF， 让 父子 进程 真 J] 














FE 地 各 








jfork 之 后 ， 子 进程 几乎 总 是 通过 调用 


























常 (pa 
自 拥 有 




























































































拷贝 父 进 程 的 数据 段 、 栈 和 堆 的 做 法 是 不 明智 的 ， 因 为 接 下 来 的 exec 系 列 函数 会 写 不 留 


























情 地 抛弃 
































ge fault) 。 此 时 ， 内 核 会 尝试 为 该 页 面 创建 一 个 新 的 物理 页 面 ， 
自己 的 物理 内 存 页， 然后 将 页 表 中 相应 的 表 项 标记 为 可 写 。 









































标记 成 
子 进程 中 有 任何 一 方 
开 将 内 容 真 正 地 复制 到 新 的 物理 页 


修改 内 容 之 前 
父 进程 页 表 物理 内 存 页 









页 表 项 211 
(只 读 ) 


从 上 面 的 描述 可 以 看 出 ， 对 于 没有 修改 的 页 面 ， 内 核 并 没有 真正 地 复 











修改 内 容 之 后 
父 进程 页 表 物理 内 存 页 










页 表 项 211 


图 4-4” 写 时 拷贝 















































入 提升 了 fork 的 性 能 ， 从 而 使 内 核 可 以 快速 地 创建 一 个 新 的 进程 。 

















从 内 核 代码 层面 来 讲 ， 其 调用 关系 如 图 4-5 所 示 。 











do fork 





图 4-5 fork 复制 内 核 页 表 流程 





剖 物 理 内 存 页 ， 仅 仅 是 复制 了 父 进程 的 页 表 。 这 种 机 制 的 引 








Linux 的 内 存 管 理 使 用 的 是 四 级 页 表 ， 如 图 4-6 所 示 ， 看 了 四 级 页 表 的 名 字 ， 也 就 不 难 推测 图 4-5 中 那些 函数 的 作 月 

















图 4-6 ”页 表 的 复制 示意 图 





在 最 后 的 copy_one_pte 函 数 中 有 如 下 代码 : 




















了。 








/* 如 果 是 写 时 拷贝 ， 那 么 无 论 是 初始 页 表 ， 还 是 拷贝 的 页 表 ， 都 设置 了 写 保护 


* 后面 无 论 父子 进程 ， 修 改 页 表 对 应 位 置 的 内 存 时 ， 都 会 触发 


page fault 


if (is cow mapping(vm flags)) { 


ptep set , Wrprotect (src 1 mm, addr, src pte); 


pte = pte wrprotect (pte); 








该 代码 将 页 表 设置 成 写 保护 ， 父 子 进程 中 任意 一 个 进程 尝试 修改 写 保护 的 页 面 时 ， 都 会 引发 负 






































数 ， 该 函数 会 负责 创建 副本 ， 即 真正 的 拷贝 。 








写 时 拷贝 技术 极 大 地 提升 了 fork 的 性 





台 
月 


E， 在 一 定 程 度 上 让 vfork 成 为 了 鸡肋 。 











页 中 断 ， 内 核 会 走向 do_ wp _page 函 


4.3.2 ”fork 之 后 父子 进程 与 文件 的 关系 





执行 fork 函 数 ， 内 核 会 复制 父 进程 所 有 的 文件 描述 符 。 对 于 父 进 程 打 开 的 所 有 文件 ， 子 进程 也 是 可 
以 操作 的 。 那 么 父子 进程 同时 操作 同一 个 文件 是 并 行 不 悖 的 ， 还 是 互相 影响 的 呢 ? 





下 面 通过 对 一 个 例子 的 讨论 来 说 明 这 个 问题 。read 函 数 并 没有 将 偏 移 量 作 为 参数 传 入 ， 但 是 每 次 调 
用 read 函 数 或 write 函 数 时 ， 却 能 够 接着 上 次 读 写 的 位 置 继续 读 写 。 原 因 是 内 核 已 经 将 偏 移 量 的 信息 记 
录 在 与 文件 描述 符 相关 的 数据 结构 里 了 。 那 么 问题 来 了 ， 父 子 进程 是 共用 一 个 文件 偏 移 量 还 是 各 有 各 
的 文件 偏 移 量 呢 ? 









































/*reaqd 和 


write 都 没有 将 


Jpos 信 息 作为 入 参 


*/ 
ssize t readl(int fd, void *buf, size t count); 
ssize t writel(lint fd, const void *buf, size t count); 





我 们 用 事实 说 话 ， 请 看 下 面 的 例子 : 





include <stdio.h> 

include <string.h> 

include <strings.h> 
include <unistd.n> 

include <sys/types.h> 
include <sys/stat.h> 
include <fcntl.h> 

include <errno.h> 

define INFILE "“./in.txt" 
define OUTFILE "“./out.txt" 
define MODE  S IRUSR |S IWUSR|S IRGRP|S IWGRP|S IROTH 
int main(void) 


{ 

















int fq in,fqd out; 

char buf [1024]; 

memset (buf, 0, 1024); 

fd in = open (INFILE, O RDONLY); 
if(fd in <0) 

{ 





fprintf (stderr,"failed to open %s, reason(%s)\n", 
INFILE, strerror (errno)); 
return 1; 
} 


fd out = open (OUTFILE,O WRONLY|O CREAT|O TRUNC,MODE); 


if(fd out < 0) 
{ 





fprintf (stderr,"failed to open %s, reason(%$s)\n", OUTFILE,strerror (errno)); 
return 1; 


} 
fork () ;/* 此 处 忽略 错误 检查 


*/ 
while (read (fd in, buf, 2) > 0) 
{ 


printf("%d: %s",getpid(),buf); 
sprintf (buf, "%d Hello,World!\n",getpid()); 
write (fd out,buf,strlen (buf)); 


Sleep (1); 
memset (buf, 0, 1024); 
} 
} 


INFILE 的 内 容 是 : 


OOPRODP 











上 面 的 程序 中 ， 父 子 进程 都 会 去 读 INFILE， 如 果 父 子 进程 各 维护 各 的 文件 偏 移 量 ， 那 么 父子 进程 
都 会 打印 出 1~6。 








事实 如 何 呢 ? 请 看 输出 内 容 : 


manu@manu-hacks:~/code/self/c/fork$ ./fork file 
6602: 
6603: 
6602: 
6603: 
6602: 
6603: 


GY tN 二 





当然 ， 有 时 候 输 出 是 这 样 的 : 


manu@manu-hacks:~/code/self/c/fork$ ./fork file 
6610: 
6611: 
6610: 
6611: 
6610: 
6611: 
6610: 


GO 二 








如 果 父 子 进程 各 自 维护 自己 的 文件 偏 移 量 ， 那 么 一 定 是 打印 出 两 套 1~6， 但 是 事实 并 非 如 此 。 无 论 
父 进 程 还 是 子 进程 调用 read 函 数 导 致 文件 偏 移 量 后 移 都 会 被 对 方 获知 ， 这 表明 父子 进程 共用 了 一 套 文件 
偏 移 量 。 

















对 于 第 二 个 输出 ， 为 什么 父子 进程 都 打印 5 呢 ? 这 是 因为 我 的 机 器 是 多 核 的 ， 父 子 进程 同时 执行 ， 
发 现 当 前 文件 偏 移 量 是 4*2， 然 后 各 上 自 去 读 了 第 8 和 第 9 字 节 ， 也 就 是 “5\n”。 











写 文件 也 是 一 样 ， 如 果 fork 之 前 打开 了 某 文件 ， 之 后 父子 进程 写 入 同一 个 文件 描述 符 而 又 不 采取 任 
何 同步 的 手段 ， 那 么 就 会 因为 共享 文件 偏 移 量 而 使 输出 相互 混合 ， 不 可 阅读 。 




















文件 描述 符 还 有 一 个 文件 描述 符 标志 (file descriptor flag) 。 目 前 只 定义 了 一 个 标志 位 : 
FD_ CLOSEXEC， 这 是 close_ on exec 标 志 位 。 细 心 阅读 open 函 数 手册 也 会 发 现 ，open 函 数 也 有 一 个 类 似 
的 标志 位 ， 即 O_CLOSEXEC， 该 标志 位 也 是 用 于 设置 文件 描述 符 标 志 的 。 























那么 这 个 标志 位 到 底 有 什么 作用 呢 ? 如 果 文 件 描述 符 中 将 这 个 标志 位 置 位 ， 那 么 调用 exec 时 会 自动 
关闭 对 应 的 文件 。 














可 是 为 什么 需要 这 个 标志 位 呢 ? 主要 是 出 于 安全 的 考虑 。 





对 于 fork 之 后 子 进程 执行 exec 这 种 场景 ， 如 果子 进程 可 以 操作 父 进程 打开 的 文件 ， 就 会 带 来 严重 的 
安全 隐患 [1] 。 一 般 来 讲 ， 调 用 exec 的 子 进 程 时 ， 因 为 它 会 另起炉灶 ， 因 此 父 进程 打开 的 文件 描述 符 也 
应 该 一 并 关闭 ， 但 事实 上 内 核 并 没有 主动 这 样 做 。 试 想 如 下 场景 ，Webserver 首 先 以 root 权 限 启动 ， 打 
开 只 有 拥有 root 权 限 才能 打开 的 端口 和 日 志 等 文件 ， 再 降 到 普通 用 户 ，fork 出 一 些 worker 进 程 ， 在 进程 
中 进行 解析 脚本 、 写 日 志 、 输 出 结果 等 操作 。 由 于 子 进程 完全 可 以 操作 父 进程 打开 的 文件 ， 因 此 子 进 
程 中 的 脚本 只 要 继续 操作 这 些 文件 描述 符 ， 就 能 越权 操作 root 用 户 才能 操作 的 文件 。 
























































为 了 解决 这 个 问题 ，Linux 引 入 了 close on exec 机 制 。 设 置 了 FD_CLOSEXEC 标 志 位 的 文件 ， 在 子 进 
程 调 用 exec 家 族 函数 时 会 将 相应 的 文件 关闭 。 而 设置 该 标志 位 的 方法 有 两 种 : 








:open 时 ， 带 上 O_CLOSEXEC 标 志 位 。 








open 时 如 果 未 设置 ， 那 就 在 后 面 调用 fcntl 函 数 的 F_SETFD 操 作 来 设置 。 





建议 使 用 第 一 种 方法 。 原 因 是 第 二 种 方法 在 某 些 时 序 条 件 下 并 不 那么 绝对 的 安全 。 考 虑 图 4-7 的 场 
景 : Thread 1 还 没 来 得 及 将 FD_CLOSEXEC 置 位 ， 由 于 Thread 2 已 经 执行 过 fork， 这 时 候 fork 出 来 的 子 进 
程 就 不 会 关闭 相应 的 文件 。 尽 管 Thread1 后 来 调用 了 fentl 的 F_SETFD 操 作 ， 但 是 为 时 已 晚 ， 文 件 已 经 泄 
露 了 。 











Thread 1 Thread 2 Process 3 


图 4-7 ”未 及 时 fcnt 导致 文件 描述 符 的 泄露 








© 注意 “图 4-7 中 ， 多 线程 程序 执行 了 fork， 仅 仅 是 为 了 示意 ， 实 际 中 并 不 鼓励 这 种 做 法 。 正 
相反 ， 这 种 做 法 是 十 分 危险 的 。 多 线程 程序 不 应 该 调用 fork 来 创建 子 进程 ， 第 8 章 会 分 析 具 体 原因 。 











前 面 提 到 ， 执 行 fork 时 ， 子 进程 会 获取 父 进程 所 有 文件 描述 符 的 副本 ， 但 是 测试 结果 表明 ， 父 子 进 
程 共 享 了 文件 的 很 多 属性 。 这 到 底 是 怎么 回 事 ?让 我 们 深入 内 核 一 探究 葛 。 














[1] Linux 系 统 文件 描述 符 继承 带 来 的 危害 请 参看 : http://www.80sec.com/security-issue-on-linux-fd- 
inheritance.html 。 





4.3.3 文件 描述 符 复 制 的 内 核实 现 


术 符 


付 task_struct 














在 内 核 的 进程 描述 


结构 体 中 ， 与 打 














文件 相关 的 变量 如 下 所 示 : 





struct task struct { 
“atrvuct files struct *filests., 
} 

















调 











fork 时 ， 内 核 会 在 copy_files 函 数 中 处 理 找 贝 父 进程 打 























的 文件 的 相关 





th 
a 





static int copy files (unsigned long clone flags, 
struct task struct *tsk) 
{ 


struct files struct *oldf, 
int erzor = 0 
oldf = current->files; 
if (!oldf) 
goto out; 
/* 创 建 线程 和 


*newf; 


VfOrk， 都 不 用 复制 父 进程 的 文件 描述 符 ， 增 加 引用 计数 即 可 


wy 

if (clone flags & CLONE FILES) { 
atomic inc(&oldf->count) 7 
goto out; 


} 
/* 对 于 


下 Ork 而 言 ， 需 要 复制 父 进 程 的 文件 描述 符 


* 
这 
newf = dup fd(oldf， 
if (!newf) 
goto out; 
tsk->files = newf; 
error = 0} 


&error); 


return error; 















































CLONE FILES 标 志 位 
一 份 就 可 
程 的 文件 





来 控制 是 否 











享 父 ; 





描述 符 。 文 件 描述 符 的 拷贝 是 通 


程 的 文件 
以 了 。 对 于 vfork 函 数 和 创建 线程 的 pthread_create 函 数 来 说 都 是 如 此 。 但 是 fork 函 数 却 不 同 ， 调 
过 内 核 的 dup_ 角 函 





她 


描述 符 。 如 果 该 标志 位 置 位 ， 则 表示 不 必 费 




















数 来 完成 的 。 





复制 
fork 函 数 时 ， 











份 

















父 进程 的 文件 描述 符 了 ， 增 加 引 





计数 ， 直 


mt 
ee 
4 



































该 标志 位 为 0， 表 示 需 要 为 子 进程 拷贝 一 份 父 进 





struct files struct *dup fdl(struct files struct *oldf, 


int *errorp) 
{ 
struct files struct *newf; 
struct file xxold fds, **new fds; 
int open files, size, i; 
struct fdtable *old fdt, *new fadt; 
*errorp = -ENOMEM; 


newf = kmem cache alloc(files cachep, GFP KERNEL); 


if (!newf) 
goto out; 

















dup_ 和 全 函数 首先 会 给 子 进程 分 配 一 个 file_struct 
记录 在 该 结构 体 中 。 其 定义 代码 如 下 : 








术 符 














洁 构 体 ， 然 后 做 一 些 赋值 操作 。 这 个 结构 体 是 进程 描述 








与 打开 文件 相关 的 数据 结构 ， 每 一 个 打 








的 文件 都 会 





struct files struct { 
atomic t count; 
struct fdtable _rceu *fat; 
struct fdtable fdtab; 
spinlock t file lock 
int next fd; 
struct embedded fqd set close on exec init; 
struct embedded fd set open . fds init; 
struct file _rcu * fd | array [NR ‘ OPEN DEFAULT]; 


和 
struct fdtable 
{ 


unsigned int max fds; 
struct file Yeu **fd; 
fd set *close on exec; 
fq set *open fds; 
struct rcu head rcu; 
struct fdtable *next; 

}; 

struct embedded fd set { 
unsigned long fds bits[1]; 

}; 


_ Cacheline aligned in smp; 


/* current fd array */ 





初 看 之 下 struct fdtable 的 内 容 与 struct files_struct 的 内 容 有 颇 多 重复 之 处 ， 包 括 close_on_exec 文 件 描述 符 
非 如 此 。struct files_struct 中 的 成 员 是 相应 数据 结构 的 实例 ， 














Linux 系 统 假设 大 多 数 的 进程 





J 开 的 文 





以 64 位 系统 为 例 ，file_struct 结 构 体 自 带 了 可 以 容纳 64 个 struct file 类 型 指针 的 数组 向 array， 也 自 带 了 两 个 大 小 为 64 的 位 图 ， 























图 

















于 记录 文件 描述 
此 在 分 配 了 file_struct 


情况 ，close_on_exec_init 位 


如 就 足以 满足 需 














。 上 基 











结构 体 后 ， 内 核 会 初始 化 file_struct 自 带 














Er 


J 


图 








二 和 





而 struct fatable 中 的 成 员 是 相应 的 指针 。 





件 不 会 太 多 。 于 是 Linux 选 择 了 一 个 long 类 型 的 位 数 〈32 位 系统 | 





区 


到 及 file 指 针 数 组 等 











文件 描述 符 位 











， 但 事实 上 并 





下 为 32 位 ，64 位 系统 下 为 64 位 ) 作为 经 验 值 。 



































符 的 FD_ CLOSEXCE 标 志 位 是 








否 置 位 。 


























只 要 进程 打开 的 文件 个 数 小 于 64，file_struct 结 构 体 自 带 
的 fdtable， 代 码 如 下 所 示 : 




















其 中 open_fds_init 位 图 用 于 记录 文件 的 
的 指针 数组 和 两 个 

















atomic set (&newf->count, 1); 
spin . lock .init (&newf->file lock); 
newf->next fd = 0; 





new fdt = &newf->fdtab; 

new fdt->max fds = NR_OPEN DEFAULT; 

new fdt->close on exec = (fd set *)&newf->close on exec init; 
new fdt->open fds = (fd set *)&newf->open fds init; 

new fdt->fd = &newf->fd array[0]; 

new fdt->next = NULL; 


























初始 化 之 后 ， 子 进程 的 fle_struct 的 情况 如 图 4-8 所 示 。 注 意 ， 此 时 file_struct 结 构 体 中 的 fat 指 针 并 未 指向 file_struct 自 带 的 struct fatable 类 型 的 fatab 变 量 。 原 因 很 人 
名， 因为 此 时 内 核 还 没有 检查 父 进 程 打开 文件 的 个 数 ， 因 此 并 不 确定 自 带 的 结构 体能 和 否 满足 需要 。 
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图 4-8 ”进程 描述 符 中 文件 相关 的 数据 结构 




































































接 下 来 ， 内 核 会 检查 父 进程 打开 文件 的 个 数 。 如 果 父 进程 打开 的 文件 超过 了 64 个 ，struct files_struct 中 自 带 的 数组 和 位 图 就 不 能 满足 需要 了 。 这 种 情况 下 内 核 会 
分 配 一 个 新 的 struct fdtable， 代 妈 如 下 








Spin Lock(&oldf->file lock); 

old fdqt = files fdtable (oldf); 

open files = count open files(old fdt); 
/* 如 果 父 进程 打开 文件 的 个 数 超过 


NR_OPEN DEFAULT*/ 
while (unlikely(open files > new fdt->max fds)) { 
spin unlock(&oldf->file lock); /* 如 果 不 是 自 带 的 


fqdtalble 而 是 曾经 分 配 的 
fdtable， 则 需要 先 释放 


A 
if (new fdt != &newf->fdtab) 
_ free fdtable (new fdt); 
/* 创 建新 的 


fdtable*/ 
new fdt = alloc fdtable(open files - 1); 
if (!new fdt) { 
*errorp = -ENOMEM; 
goto out release; 


} 
/* 如 果 超出 了 系统 限制 ， 则 返回 


EMFILE*/ 
if (unlikely (new fdt->max fds < open files)) { 
free fdtable (new fat); 
*errorp = -EMFILE; 
goto out release; 


} 

spin lock(&oldf->file lock); 

old fqt = files fdtable (oldf); 

open files = count open files(old fdt); 























alloc_fdtable 所 做 的 事情 ， 不 过 是 分 配 fatable 结 构 体 本 身 ， 以 及 分 配 一 个 指针 数组 和 两 个 位 图 〈 如 图 4-9 所 示 ) 。 分 配 之 前 会 根据 父 进程 打开 文件 的 数目 ， 计 算 
一 个 合理 的 值 nrY"， 以 确保 分 配 的 数组 和 位 图 能 够 满足 需要 。 
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图 4-9 alloc_fdtable 原 理 





















































无 论 是 使 用 file_struct 结 构 体 自 带 的 fatable， 还 是 使 用 alloc_fatable 分 配 的 fatable， 接 下 来 要 做 的 事情 都 一 样 ， 即 将 父 进程 的 两 个 位 图 信息 和 打开 文件 的 struct file 类 
型 指针 拷贝 到 子 进程 的 对 应 数据 结构 中 ， 代 码 如 下 : 
























































上 











old fds = old fdt->fd;  /* 父 进程 的 


Struct file 指针 数组 


*/new_fds = new fdt->fd;  /* 子 进程 的 


Struct file 指针 数组 


**//* 拷贝 打开 文件 位 图 


*/memcpy (new_ fdt->open fds->fds bits,old fdt->open fds->fds bits, open files/8);/* 拷贝 


Close_on exec 位 图 


*/memcpy (new_fdt->close on exec->fds bits,old fdt->close on exec->fds bits, open files/8);for (i = open files; i != 0; i--) { struct file *f = *old fds++} 1£ (£) 4 


1 */ } else { FD CLR(open files - i, new fdt->open fds); }/* 子 进程 的 


struct file 类 型 指针 , 


* 指 向 和 父 进程 相同 的 


struct file 结构 体 


*/ rcu assign pointer(*new fds++, f); }spin unlock (goldf->file lock);/* compute the remainder to be cleared */size = (new fdt->max fds - open files) * sizeof(struct file * 


Struct file 结 构 的 指针 清 零 


*/memset (new_fds，0， Size) ; /* 将 尚未 分 配 到 的 位 图 区 域 清 零 


*/if (new fdt->max fds > open files) { int left = (new fdt->max fds-open files)/8; int start = open files / (8 * sizeof(unsigned long)); memset (&new fdt->open fds->fds 





后 注意 ”procfs 的 /proc/PID/status 中 的 FDSize， 记 录 了 当前 fdtable 的 大 小 : 








manu@manu-hacks:~$ cat /proc/1/status 
FDSize: 128 




















当然 了 ，FDSize 记 录 的 是 目前 fdtable 能 容纳 的 struct file 指 针 ， 而 不 是 已 经 打开 的 文件 个 数 ， 已 经 打开 的 文件 记录 在 /proc/PID/ 伺 中 。 

















通过 对 上 述 流程 的 梳理 ， 不 难看 出 ， 父 子 进程 之 间 拷 贝 的 是 struct file 的 指针 ， 而 不 是 struct file 的 实例 ， 父 子 进程 的 struct file 类 型 指针 ， 都 指向 同一 个 struct file 实 
例 。fork 之 后 ， 父 子 进程 的 文件 描述 符 关系 如 图 4-10 所 示 。 








父 进 程 fork 之 后 的 子 进程 
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图 4-10” fork 之后， 父子 进 程 的 文件 描述 符 关系 
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下 面 来 看 看 struct file 成 员 变 量 : 
struct file{ 
unsigned int £f flags 
fmode t £_modt 
16f£ t £_pos; /* 文 件 位 置 指针 的 当前 值 ， 即 文件 偏 移 量 


sf 








看 到 此 处 ， 就 不 难 理解 父子 进程 是 如 何 共享 文件 偏 移 量 的 了 ， 那 是 因为 父子 进程 的 指针 都 指向 了 同一 个 struct file 结 构 体 。 








4.4 进程 的 创建 之 vfork (〈 ) 











在 早期 的 实现 中 ，fork 没 有 实现 写 时 拷贝 机 制 ， 而 是 直接 对 父 进程 的 数据 段 、 堆 和 栈 进行 完全 找 
贝 ， 效 率 十 分 低下 。 很 多 程序 在 fork 一 个 子 进程 后 ， 会 紧 接 着 执行 exec 家 族 函 数 ， 这 更 是 一 种 浪费 。 所 
以 BSD 引 入 了 vfork。 既 然 fork 之 后 会 执行 exec 函 数 ， 找 贝 父 进程 的 内 存 数 据 就 变 成 了 一 种 无 意义 的 行 
为 ， 所 以 引入 的 vfork 压 根 就 不 会 拷贝 父 进程 的 内 存 数据 ， 而 是 直接 共享 。 再 后 来 Linux 引 入 了 写 时 找 贝 
的 机 制 ， 其 效率 提高 了 很 多 ， 这 样 一 来 ，vfork 其 实 就 可 以 退出 历史 舞台 了 。 除 了 一 些 需 要 将 性 能 优化 
到 极致 的 场景 ， 大 部 分 情况 下 不 需要 再 使 用 vfork 疯 数 了 。 






























































vfork 会 创建 一 个 子 进程 ， 该 子 进程 会 共享 父 进程 的 内 存 数据 ， 而 且 系 统 将 保证 子 进程 先 于 父 进 程 
获得 调度 。 子 进程 也 会 共享 父 进程 的 地 址 空间 ， 而 父 进程 将 被 一 直 挂 起 ， 直 到 子 进程 退出 或 执行 exec。 














注意 ，vfork 之 后 ， 子 进程 如 果 返 回 ， 则 不 要 调用 return， 而 应 该 使 用 _exit 函 数 。 如 果 使 用 return， 就 
会 出 现 诡 异 的 错误 由。 请 看 下 面 的 示例 代码 : 





#include <stdio.h> 
#include <stdlib.h> 
#include <unistd.h> 
int glob = 88 ，; 
int main(void) { 
int var; 
var = 88; 
pid 七 pid; 
if ((pid = vfork()) < 0) { 
printf ("vfork, error")» 
exit (-1); 
} else if (pid == 0) { /* 子 进 程 


六 
Wa 
globt++; 
return 0; 
}printf ("pid=%d, glob=%d, var=%d\n",getpid(), glob, var); 
return 0; 





调用 子 进程 ， 如 果 使 用 return 返 回 ， 就 意味 着 main 函 数 返 回 了 ， 因 为 栈 是 父子 进程 共享 的 ， 所 以 程 
序 的 函数 栈 发 生 了 变化 。main 函 数 return 之 后 ， 通 常会 调用 exit 系 的 函数 ， 父 进程 收 到 子 进程 的 exit 之 
后 ， 就 会 开始 从 vfork 芭 回 ， 但 是 这 时 整个 main 函 数 的 栈 都 已 经 不 复 存 在 了 ， 所 以 父 进程 压根 无 法 执 
行 。 于 是 会 返回 一 个 诡异 的 栈 地 址 ， 对 于 在 某 些 内 核 版 本 中 ， 进 程 会 直接 报 栈 错误 然后 退出 ， 但 是 在 
某 些 内 核 版 本 中 ， 有 可 能 就 会 再 次 进出 main， 于 是 进入 一 个 无 限 循环 ， 直 到 vfork 返 回 错 误 。 笔 者 的 
Ubuntu 版 本 就 是 后 者 。 





























一 般 来 说 ，vfork 创 建 的 子 进程 会 执行 exec， 执 行 完 exec 后 应 该 调用 _exit 返 回 。 注 意 是 _ exit 而 不 是 
xit。 因 为 exit 会 导致 父 进程 stdio 缓 冲 区 的 冲刷 和 关闭 。 我 们 会 在 后 面 讲述 exit 和 exit 的 区 别 。 











[1] 请 参考 著名 程序 员 陈 能 的 《vfork 挂 掉 的 一 个 问题 》 一 文 


4.$ daemon 进 程 的 创建 











daemon 进 程 又 被 称 为 守护 进程 ， 一 般 来 说 它 有 以 下 两 个 特点 : 





.生命 周期 很 长 ， 一 旦 启动 ， 正 常情 况 下 不 会 终止 ， 一 直 运 行 到 系统 退出 。 但 凡事 无 绝对 : daemon 
进程 其 实 也 是 可 以 停止 的 ， 如 很 多 daemon 提 供 了 stop 命 令 ， 执 行 stop 命 令 就 可 以 终止 daemon， 或 者 通过 
发 送信 号 将 其 杀 死 ， 又 或 者 因为 daemon 进 程 代码 存在 bug 而 异常 退出 。 这 些 退 出 一 般 都 是 由 手工 操作 或 
办 异常 引发 的 。 














:在 后 台 执 行 ， 并 且 不 与 任何 控制 终端 相关 联 。 即 使 daemon 进 程 是 从 终端 命令 行 启动 的 ， 终 端 相关 
的 信号 如 SIGINT、SIGQUIT 和 SIGTSTP， 以 及 关闭 终端 ， 都 不 会 影响 到 daemon 进 程 的 继续 执行 。 














习惯 上 daemon 进 程 的 名 字 通 常 以 4 结尾 ， 如 sshd、rsyslogd 等 。 但 这 仅仅 是 习惯 ， 并 非 一 定 要 如 此 。 











如 何 使 一 个 进程 变 成 daemon 进 程 ， 或 者 说 编写 daemon 进 程 ， 需 要 遵循 哪些 规则 或 步骤 呢 ? 











一 般 来 讲 ， 创 建 一 个 daemon 进 程 的 步骤 被 概括 地 称 为 double-fork magic。 细 细 说 来 ， 需 要 以 下 步 





(1) 执行 fork《〈) 函数 ， 父 进程 退出 ， 子 进程 继续 





执行 这 一 步 ， 原 因 有 二 : 





: 父 进程 有 可 能 是 进程 组 的 组 长 (在 命令 行 启动 的 情况 下 ) ， 从 而 不 能 够 执行 后 面 要 执行 的 setsid 函 
数 ， 子 进程 继承 了 父 进程 的 进程 组 ID， 并 且 拥 有 自己 的 进程 ID， 一 定 不 会 是 进程 组 的 组 长 ， 所 以 子 进 
程 一 定 可 以 执行 后 面 要 执行 的 setsid 函 数 。 





























.如果 daemon 是 从 终端 命令 行 启动 的 ， 那 么 父 进程 退出 会 被 shell 检 测 到 ，shell 会 显示 shell 提 示 符 ， 
让 子 进 程 在 后 台 执行 。 





(2) 子 进程 执行 如 下 三 个 步骤 ， 以 摆脱 与 环境 的 关系 


1) 修改 进程 的 当前 目录 为 根 目 录 (/) 。 








这 样 做 是 有 原因 的 ， 因 为 daemon 一 直 在 运行 ， 如 果 当 前 工作 路 径 上 包含 有 根 文件 系统 以 外 的 其 他 
文件 系统 ， 那 么 这 些 文件 系统 将 无 法 秋 载 。 因 此 ， 常 规 是 将 当前 工作 目录 切换 成 根 目录 ， 当 然 也 可 以 
是 其 他 目录 ， 只 要 确保 该 目录 所 在 的 文件 系统 不 会 被 色 载 即 可 。 





























ehdae(™"/") 











2) 调用 setsid 函 数 。 这 个 函数 的 目的 是 切断 与 控制 终端 的 所 有 关系 ， 并 且 创 建 一 个 新 的 会 话 。 























这 一 步 比较 关键 ， 因 为 这 一 步 确 保 了 子 进程 不 再 归属 于 控制 终端 所 关联 的 会 话 。 因 此 无 论 终 端 是 
否 发 送 SIGINT、SIGQUIT 或 SIGTSTP 信 和 号， 也 无 论 终 端 是 否 断 开 ， 都 与 要 创建 的 daemon 进 程 无 关 ， 不 


会 影响 到 daemon 进 程 的 继续 执行 。 




















3) 设置 文件 模式 创建 掩 码 为 0。 





umask (0) 





这 一 步 的 目的 是 让 daemon 进 程 创建 文件 的 权限 属性 与 shell 脱 离 关 系 。 因 为 默认 情况 下 ， 进 程 的 
umask 来 源 于 父 进程 shell 的 umask。 如 果 不 执 行 umask (0) ， 那 么 父 进程 shell 的 umask 就 会 影响 到 daemon 
进程 的 umask。 如 果 用 户 改 变 了 shell 的 umask， 那 么 也 就 相当 于 改变 了 daemon 的 umask， 就 会 造成 daemon 
进程 每 次 执行 的 umask 信 息 可 能 会 不 一 致 。 




















(3) 再 次 执行 fork， 父 进程 退出 ， 子 进程 继续 








执行 完 前 面 两 步 之 后 ， 可 以 说 已 经 比较 圆满 了 : 新 建 会 话 ， 进 程 是 会 话 的 首 进程 ， 也 是 进程 组 的 
首 进 程 。 进 程 ID、 进 程 组 ID 和 会 话 ID， 三 者 的 值 相同 ， 进 程 和 终端 无 关联 。 那 么 这 里 为 何 还 要 再 执行 
一 次 fork 函 数 呢 ? 


























原因 是 ，daemon 进 程 有 可 能 会 打开 一 个 终端 设备 ， 即 daemon 进 程 可 能 会 根据 需要 ， 执 行 类 似 如 下 
的 代码 : 








int fd = open("/dev/console", O RDWR); 





这 个 打开 的 终端 设备 是 否 会 成 为 daemon 进 程 的 控制 终端 ， 取 决 于 两 点 : 


-daemon 进程 是 不 是 会 话 的 首 进程 。 





:系统 实现 。 (BSD 风 格 的 实现 不 会 成 为 daemon 进 程 的 控制 终端 ， 但 是 POSIX 标 准 说 这 由 具体 实现 
来 决定 ) 。 























既然 如 此 ， 为 了 确保 万 无 一 失 ， 只 有 确保 daemon 进 程 不 是 会 话 的 首 进 程 ， 才 能 保证 打开 的 终端 设 
备 不 会 自动 成 为 控制 终端 。 因 此 ， 不 得 不 执行 第 二 次 fork，fbrk 之 后 ， 父 进程 退出 ， 子 进程 继续 。 这 
时 ， 子 进程 不 再 是 会 话 的 首 进程 ， 也 不 是 进程 组 的 首 进 程 了 。 












































(4) 关闭 标准 输入 〈stdin) 、 标 准 输出 〈stdout) 和 标准 错误 〈stderr ) 














因为 文件 描述 符 0、1 和 2 指向 的 就 是 控制 终端 。daemon 进 程 已 经 不 再 与 任意 控制 终端 相关 联 ， 因 此 
这 三 者 都 没有 意义 。 一 般 来 讲 ， 关 闭 了 之 后 ， 会 打开 /dev/null， 并 执行 dup2 函 数 ， 将 0、1 和 2 重 定向 
到 /dev/null。 这 个 重 定向 是 有 意义 的 ， 防 止 了 后 面 的 程序 在 文件 描述 符 0、1 和 2 上 执行 WO 库 函 数 而 导致 
报错 。 
























































至 此 ， 即 完成 了 daemon 进 程 的 创建 ， 进 程 可 以 开始 自己 真正 的 工作 了 。 








上 述 步 骤 比 较 繁 琐 ， 对 于 C 语 言 而 言 ，glibc 提 供 了 daemon 函 数 ， 从 而 帮 有 我 们 将 程序 转化 成 daemon 进 





#include <unistd.h> 
int daemon (int nochdir, int noclose); 











该 函数 有 两 个 入 参 ， 分 别 控制 一 种 行为 ， 具 体 如 下 。 


其 中 的 nochdir， 用 来 控制 是 否 将 当前 工作 目录 切换 到 根 目录 。 








0: 将 当前 工作 目录 切换 到 /。 


1: 保持 当前 工作 目录 不 变 。 


而 noclose， 用 来 控制 是 否 将 标准 输入 、 标 准 输出 和 标准 错误 重 定向 到 /devnull。 


.0: 将 标准 输入 、 标 准 输 出 和 标准 错误 重 定向 到 /dev/null。 


1: 保持 标准 输入 、 标 准 输出 和 标准 错误 不 变 。 





一 般 情况 下 ， 这 两 个 入 参 都 要 为 0。 





ret = daemon (0,0) 


成 功 时 ，daemon 了 水 数 返 回 0; 失败 时 ， 返 回 -1， 并 置 errno。 因 为 daemon 函 数 内 部 会 调用 fork 函 数 和 
setsid 函 数 ， 所 以 出 错时 errno 可 以 查看 fork 函 数 和 setsid 函 数 的 出 错 情 形 。 





glibc 的 daemon 函 数 做 的 事情 ， 和 前 面 讨论 的 大 体 一 致 ， 但 是 做 得 并 不 彻底 ， 没 有 执行 第 二 次 的 
fork。 











4.6 进程 的 终止 


在 不 考虑 线程 的 情况 下 ， 进 程 的 退出 有 以 下 5 种 方式 。 














正常 退出 有 3 种 : 


.从 main 函 数 return 返 回 








.调用 abort 


4.6.1 。_exit 函 数 


_exit 函 数 的 接口 定义 如 下 : 








#include <unistd.h> 
void exit(int status); 























_exit 函 数 中 status 参 数 定义 了 进程 的 终止 状态 ， 父 进程 可 以 通 

























































































过 wait () 来 获取 该 状态 值 。 

























































































需要 注意 的 是 返回 值 ， 虽 然 status 是 int 型 ， 但 是 仅 有 低 8 位 可 以 被 父 进程 所 用 。 所 以 写 exit (-1) 结束 进程 时 ， 在 终端 执行 “$? ”会 发 现 返 回 值 
是 255。 
如 果 是 shell 相 关 的 编程 ，shell 可 能 需要 获取 进程 的 退出 值 ， 那 么 退出 值 最 好 不 要 大 于 128。 如 果 退 出 值 大 于 128， 会 给 shell 带 来 困扰 。POSIX 
标准 规定 了 退出 状态 及 其 含义 如 表 4-2 所 示 。 
表 4-2 ”shell 编 程 中 退出 状态 及 其 含义 
值 富 光 
0 命令 成 功 执行 并 退出 
1 一 125 命令 未 成 功 地 退出 ， 有 具体 含义 由 各 上 自 的 命令 来 定义 
126 命令 找到 了 ， 文 件 无 法 执行 
( 续 ) 
值 a 
127 命令 找 不 到 
>128 命令 因 收 到 信号 而 死亡 
下 面 的 命令 被 SIGINT 信 号 〈signo=2) 中 断 ， 返 回 了 130。 如 程序 通过 exit 返 回 130， 与 其 配合 工作 的 shell 就 可 能 会 误 判 为 收 到 信号 而 退出 。 
manuemanu hacks:~/code/me/exitS$ Sleep 10000 
人 :~/code/me/exit$ $? 
1 30: 未 找到 命令 
用 户 调用 _exit 函 数 ， 本 质 上 是 调用 exit_group 系 统 调 用 。 这 点 在 前 面 已 经 详细 介绍 过 ， 在 此 就 不 再 袭 述 了 






















































































4.6.2 ”exit 函数 


exit 函 数 更 常见 一 些 ， 其 接口 定义 如 下 : 





#include <stdlib.h> 
void exit (int status); 





exit () 函数 的 最 后 也 会 调用 _exit () 函数 ， 但 是 exit 在 调用 _exit 之 前 ， 还 做 了 其 他 工作 : 
1) 执行 用 户 通过 调用 atexit 函 数 或 on_exit 定 义 的 清理 函数 。 


2) 关闭 所 有 打开 的 流 (stream) ， 所 有 绥 冲 的 数据 均 被 写 入 flush) ， 通 过 tmpfile 创 建 的 临时 文件 
都 会 被 删除 。 


3) 调用 _exit。 


图 4-11 给 出 了 exit 函 数 和 _exit 函 数 的 差异 。 


执行 用 户 定 义 的 清理 函数 


冲刷 缓冲 区 ， 关 闭 流 ， 
清除 打开 的 临时 文件 


通过 exit_group 系 统 调用 ， 执 行内 核 清 理工 作 


进程 终止 运行 





图 4-11 exit 和 和 _exit 比 较 


下 面 介 绍 exit 函 数 和 _exit 函 数 的 不 同 之 处 。 








首先 是 exit 函 数 会 执行 用 户 注 册 的 清理 函数 。 用 户 可 以 通过 调用 atexit () 函数 或 on _ exit () 函数 来 


























定义 清理 函数 。 这 些 清理 函数 在 调用 return 或 调用 exit 时 会 被 执行 。 执 行 顺序 与 函数 注册 的 顺序 相反 。 当 
进程 收 到 致命 信号 而 退出 时 ， 注 册 的 清理 函数 不 会 被 执行 ， 当 进程 调用 _exit 退 出 时 ， 注 册 的 清理 函数 
不 会 被 执行 ， 当 执行 到 某 个 清理 函数 时 ， 闭 收 到 致命 信号 或 清理 函数 调用 了 _exit〈() 函数 ， 那 么 该 清 
理 函 数 不 会 返回 ， 从 而 导致 排 在 后 面 的 需要 执行 的 清理 函数 都 会 被 丢弃 。 










































































其 次 是 exit 函 数 会 冲刷 flush》 标准 1O 库 的 缓冲 并 关闭 流 。glibc 提 供 的 很 多 与 VO 相关 的 函数 都 提 


~、 


供 了 缓冲 区 ， 用 于 缓存 大 块 数 据 。 

















缓冲 有 三 种 方式 无 缓冲 〈_ IONBF) 、 行 缓冲 〈_ IOLBF) 和 全 缓冲 (_IOFBF) 。 


:无 缓冲 : 就 是 没有 缓冲 区 ， 每 次 调用 stdio 库 函数 都 会 立刻 调用 read/write 系 统 调用 。 


' 行 缓冲 : 对 于 输出 流 ， 收 到 换行 符 之 前 ， 一 律 缓冲 数据 ， 除 非 缓冲 区 满 了 。 对 于 输入 流 ， 每 次 读 
取 一 行 数据 。 


:全 缓冲 : 就 是 缓冲 区 满 之 前 ， 不 会 调用 read/write 系 统 调 用 来 进行 读 写 操作 。 











对 于 后 两 种 缓冲 ， 可 能 会 出 现 这 种 情况 ， 进 程 退出 时 ， 绥 冲 区 里 面 可 能 还 有 未 冲刷 的 数据 。 如 果 
不 冲刷 缓冲 区 ， 绥 冲 区 的 数据 就 会 丢失 。 比 如 行 缓冲 述 述 没有 等 到 换行 符 ， 又 或 者 全 缓冲 没有 等 到 组 
冲 区 满 。 尤 其 是 后 者 ， 很 容易 出 现 ， 因 为 gibc 的 缓冲 区 默认 是 8192 字 节 。exit 函 数 在 关闭 流 之 前 ， 会 冲 
刷 缓冲 区 的 数据 ， 确 保 缓冲 区 里 的 数据 不 会 丢失 。 





























#include <stdio.h> 

#include <stdlib.h> 
#include <unistd.h> 
void foo() 


fprintf (stderr, "foo says bye.\n"); 
void bar() 
fprintf (stderr, "bar says bye.\n"); 
} 


int main(int argc, char **argv) 


atexit (foo); 
atexit (bar); 





fprintf (stdout,"Oops ... forgot a newline!"); 

Sleep (2); 

if (argc > 1 && strcmp (argv[1],"exit") == 0) 
exit (0); 

if (argc > 1 && strcmpl(argv[l1]," exit") == 0) 
_exit (0); 

return 0; 





注意 上 面 的 示例 代码 ，fprintf 打 印 的 字符 串 是 没有 换行 符 的 ， 对 于 标准 输出 流 stdout， 采 用 的 是 行 绥 
冲 ， 收 到 换行 符 之 前 是 不 会 有 输出 的 。 输 出 情况 如 下 : 





manu@manu-hacks:exit$ ./test exit 

bar says bye. 

foo says bye. 

Oops ... forgot a newline!manu@manu-hacks:exits$ 
manu@manu-hacks:exits$ 

manu@manu-hacks:exit$ ./test 


bar says bye. 

foo says bye. 

Oops ... forgot a newline!manu@manu-hacks:exits$ 
manu@manu-hacks:exit$ 

manuemanu-hacks :exitS ./test exit 
manuemanu-hacks:~/code/self/c/exitS 











尽管 缓冲 区 里 的 数据 没有 等 到 换行 符 ， 但 是 无 论 是 调用 return 返 回 还 是 调用 exit 返 回 ， 绥 冲 区 里 的 数 





据 都 会 被 冲刷 ，“Oops...forgot a newline ! ”都 会 被 输出 。 因 为 exit 〈) 函数 会 负责 此 事 。 从 测试 代码 的 输 
出 也 可 以 看 出 ，exit () 函数 首先 执行 的 是 用 户 注 册 的 清理 函数 ， 然 后 才 执行 了 缓冲 区 的 神 刷 。 




















第 三 ， 存 在 临时 文件 ，exit 函 数 会 负责 将 临时 文件 删除 ， 这 点 在 第 3 章 中 己 经 介绍 过 ， 此 处 就 不 再 
更 述 了 。 


exit 函 数 的 最 后 调用 了 _exit 〈() 函数 ， 最 终 殊 途 同 归 ， 走 向 内 核 清理 





| 


O 


4.6.3 ”return 退 出 


return 是 一 种 更 常见 的 终止 进程 的 方法 。 执 行 return (n) 等 同 于 执行 exit (n) ， 因 为 调用 main () 
的 运行 时 函数 会 将 main 的 返回 值 当 作 exit 的 参数 。 


4.7.1 僵尸 进程 


进程 就 像 一 个 生命 体 ， 通 过 fork《〈) 函数 ， 子 进程 哑 啤 哈 地 。 有 的 子 进 程 子 承 父 业 ， 继 续 执 行 与 父 
进程 一 样 的 程序 “相同 的 代码 段 ， 尽 管 可 能 是 不 同 的 程序 分 支 ) ， 有 的 子 进 程 则 比较 叛逆 ， 通 过 exec 离 

















家 出 走 ， 走 向 与 父 进 程 完 全 不 同 的 道路 。 








令 人 悲伤 的 是 ， 如 同 所 有 的 生命 体 一 样 ， 进 程 也 会 消亡 。 进 程 退出 时 会 进行 内 核 清 理 ， 基 本 就 是 














释放 进程 所 有 的 资源 ， 这 些 资 源 包括 内 存 资源 、 文 件 资源 、 信 号 量 











资源 、 共 享 内 存 资源 ， 或 者 引用 计 


数 减 一 ， 或 者 彻底 释放 。 不 过 ， 进 程 的 退出 其 实 并 没有 将 所 有 的 资源 完全 释放 ， 仍 保留 了 少量 的 资 


源 ， 比 如 进程 的 PID 依 然 被 占用 着 ， 不 可 被 系统 分 配 。 此 时 的 进程 


其 运行 ， 进 程 进入 僵尸 状态 。 








不 可 运行 ， 事 实 上 也 没有 地 址 空间 让 








为 什么 进程 退出 之 后 不 将 所 有 的 资源 释放 ， 从 此 灰飞烟灭 ， 
进入 僵尸 状态 呢 ? 看 看 僵尸 进程 依然 占有 的 系统 资源 ， 我 们 就 能 3 





有 进程 控制 块 task_struct、 内 核 栈 等 。 这 些 资 源 不 释放 是 为 了 提供 一 


出 ， 是 收 到 信号 退出 还 是 正常 退出 ， 进 程 退出 码 是 多 少 ， 进 程 一 








一 了 再 
获得 答 


些 





1 中 


共 消 耗 


昌 


了 ， 反 和 而 非 要 保留 少量 资源 ， 


案 。 僵 尸 进程 依然 保留 的 资源 
E 要 的 信息 ， 比 如 进程 为 何 退 


了 多 少 系统 CPU 时 间 ， 多 少 用 





户 CPU 时 间 ， 收 到 了 多 少 信号 ， 发 生 了 多 少 次 上 下 文 切 换 ， 最 大 内 存 驻 

















留 集 是 多 少 ， 产 生 多 少 缺 页 中 








其? 等 等 。 这 些 信 息 ， 就 像 墓志 铬 ， 总 结 了 进程 的 一 生 。 如 果 没 有 这 个 僵尸 状态 ， 进 程 的 这 些 信息 也 
会 随 之 流逝 ， 系 统 也 将 再 也 没有 机 会 获知 该 进程 的 相关 信息 了 。 因 此 进程 退出 后 ， 会 保留 少量 的 资 





源 ， 等 待 父 进程 前 来 收集 这 些 信 息 。 一 旦 父 进程 收集 了 这 些 信 息 之 后 〈 通 














过 调用 下 面 提 到 的 


wait/waitpid 等 函数 ) ， 这 些 残存 的 资源 完成 了 它 的 使 合 ， 就 可 以 释放 了 ， 进 程 就 脱离 僵尸 状态 ， 彻 底 


消失 了 。 














从 上 面 的 讨论 可 以 看 出 ， 制 造 一 个 僵尸 进程 是 一 件 很 容易 的 事情 ， 只 要 父 进程 调用 fork 创 建 子 进 
程 ， 子 进程 退出 后 ， 父 进程 如 果 不 调用 wait 或 waitpid 来 获取 子 进程 的 退出 信息 ， 子 进程 就 会 沦 为 僵尸 进 





程 。 示 例 代码 如 下 : 


#include <stdio.h> 
#include <stdlib.h> 
#include <sys/types.h> 
#include <unistd.h> 
int main() 
{ 

pid 七 Pid; 

pid=fork (); 

if (pid<0) 


/* 如 果 出 错 








ey 
printf ("error occurred!\n") 


} 
else if (pid==0) 


/* 子 进程 
#7 
exit (0) 
} 
else 
{ 
/* 父 进程 
*/ 
sleep (300); /* 休眠 
300 秒 
*/ 
Wait (NULL); /* 获取 僵尸 进程 的 退出 信息 
*/ 


} 


return 0; 





上 面 的 例子 中 父 进 程 休眠 300 秒 后 才 会 
成 僵尸 状态 ， 苦 苦 等 待 父 进程 来 获取 退出 信息 。 在 这 


如 何 查 看 一 个 进程 是 否 处 于 僵尸 状态 呢 ? 


外 procfs 提 供 的 status 信 息 


调用 wait 来 获取 子 进程 的 退出 信息 。 而 子 进程 退 
300 秒 左右 的 时 间 


ps 命令 输出 的 进程 状态 Z， 就 表示 进程 处 于 僵尸 
中 的 State 给 出 的 值 是 Z (zombie) ， 





出 之 后 会 变 


个 僵尸 进程 。 








， 子 进程 就 是 


hh 


HH 











状态 ,为 








也 表明 进程 处 于 僵尸 状态 。 





ps ax 
3940 pts/10 S 0:00 ./zombie 
3941 pts/10 Zz 0:00 [zombie] <defunct> 
cat /proc/3941/status 
Name: zombie 
State 2 (zombie) 
Tgid 3941 
Ngid 0 
Pid: 3941 
PPid 3940 





进程 一 旦 进入 僵尸 状态 
谁 也 没有 办 法 杀 死 一 个 已 经 死去 的 进程 。 











清除 僵尸 进程 有 以 下 两 种 方法 : 


` 父 进程 调用 wait 函 数 ， 为 子 进程 “ 收 尸 ”。 








: 父 进 程 退出 ，init 进 程 会 为 子 进程 “ 收 己 ”。 


， 就 进入 了 一 种 刀枪 不 入 的 状态 ， 


“杀人 不 上 县 眼 ”的 kill-9 也 无 能 为 力 ， 因 为 


外 ， 比 较 重 要 的 是 进程 ID。 伪 尸 进程 并 没有 将 自己 的 进程 DD 归还 








一 般 而 言 ， 系 统 不 希望 大 量 进程 长 期 处 于 僵尸 状态 ， 因 为 会 浪 
































因此 系统 不 能 将 该 ID 分 配给 其 他 进程 。 





置 了 SA_NOCLDWAIT 标 志 位 ， 


情 ” 











费 系统 资源 。 除 了 少量 的 内 存 资源 





给 系统 ， 而 是 依然 占有 这 个 进程 ID， 





对 于 编程 来 将， 如 何 防范 僵尸 进程 的 产生 呢 ? 答案 是 具体 情况 





具体 分 析 。 


如 果 我 们 不 关心 子 进程 的 退出 状态 ， 就 应 该 将 父 进程 对 SIGCHLD 的 处 理 函 数 设置 为 SIG_IGN， 或 








者 在 调用 sigaction 函 数 时 设置 SA_NOCLDWAIT 标 志 位 。 这 两 者 都 会 明确 告诉 子 进程 ， 父 进程 很 “ 绝 














true， 子 进程 发 现 autoreap 为 true 也 就 “死心 "了 ， 不 会 进入 僵尸 状态 ， 
靳 ”了 。 


如 果 父 进程 关心 子 进程 的 退出 信息 ， 则 应 该 在 流程 上 妥善 设计 





于 僵尸 状态 的 时 间 不 会 太 久 。 


程 池 ， 


有 


全 过 7 








对 于 创建 了 很 多 子 进程 的 应 用 来 说 ， 知 道子 进程 的 返回 值 是 有 意 



































过 进程 池 里 的 子 进程 来 提供 服务 。 当 子 进程 退出 的 时 候 ，4 























契 


子 进程 的 “死因 ”， 


从 而 采取 更 有 针对 性 的 措施 。 








， 不 会 为 子 进程 “ 收 记 "。 子 进程 退出 的 时 候 ， 内 核 会 检查 父 进程 的 SIGCHLD 信 号 处 理 结构 体 是 否 设 
或 者 是 否 将 信号 处 理 函 数 显 式 地 设 为 SIG_IGN。 如 果 是 ， 则 autoreap 为 


而 是 调用 release task 函数 “自行 了 


， 能 够 及 时 地 调用 wait， 使 子 进程 处 





义 的 。 比 如 说 父 进程 维护 一 个 进 
父 进程 需要 了 解 子 进程 的 返回 值 来 











4.7.2 “等待 子 进程 之 wait () 














Linux 提 供 了 wait 〈) 函数 来 获取 子 进 程 的 退出 状 














include <sys/wait.h> 
pid t wait (int *status); 




















成 功 时 ， 返 回 已 退出 子 进程 的 进程 ID; 失败 时 ， 则 返回 -1 并 设置 errno， 常见 的 errno 及 说 明 见 表 4-3。 














表 4-3 ”wait 函数 的 出 错 情况 





errno 说 明 
ECHLD 调用 进程 时 发 现 并 没有 子 进程 需要 等 待 
EINTR 国 数 被 信号 中 断 




































































注意 父子 进程 是 两 个 进程 ， 子 进程 退出 和 父 进程 调用 wait《〈) 函数 来 获取 子 进程 的 退出 状态 在 时 间 上 是 独立 的 事件 ， 因 此 会 出 现 以 下 两 种 情 















































: 子 进程 先 退 出 ， 父 进程 后 调用 wait () 函数 。 












































' 父 进程 先 调用 wait () 函数 ， 子 进程 后 退出 。 


上 上 



































对 于 第 一 种 情况 ， 子 进程 几乎 已 经 销毁 了 自己 所 有 的 资源 ， 只 留 下 少量 的 信息 ， 苦 若 等 待 父 进程 来 " 收 户 "。 当 父 进程 调用 wait 〈) 函数 的 时 
候 ， 若 守 寒 窗 十 八 载 的 子 进 程 终于 等 到 了 父 进程 来 " 收 户 ”， 这 种 情况 下 ， 父 进程 获取 到 子 进程 的 状态 信息 ，wait 函 数 立 刻 返 回 。 
































































































































对 于 第 二 种 情况 ， 父 进程 先 调用 wait〈) 函数 ， 调 用 时 并 无 子 进程 退出 ， 该 函数 调用 就 会 陷入 阻塞 状态 ， 直 到 某 个 子 进程 退出 。 

























































































wait《 ) 函数 等 待 的 是 任意 一 个 子 进程 ， 任 何 一 个 子 进程 退出 ， 都 可 以 让 其 返回 。 当 多 个 子 进程 都 处 于 僵尸 状态 ，wait〈) 函数 获取 到 其 中 
个 子 进程 的 信息 后 立刻 返回 。 由 于 wait () 函数 不 会 接受 pid t 类 型 的 入 参 ， 所 以 它 无 法 明确 地 等 待 特定 的 子 进 程 。 


































































































个 进程 如 何等 待 所 有 的 子 进 程 退出 呢 ? wait 〈) 函数 返回 有 三 种 可 能 性 : 





















































:等 到 了 子 进程 退出 ， 获 取 其 退出 信息 ， 返 回 子 进程 的 进程 ID。 






































:等 待 过 程 中 ， 收 到 了 信和 号， 信和 号 打 断 了 系统 调用 ， 并 且 注 册 信和 号 处 理 函 数 时 并 没有 设置 SA_RESTART 标 志 位 ， 系 统 调用 不 会 被 寻 
启 ，wait () 函数 返回 -1， 并 且 将 errno 设 置 为 EINTR 。 





[hh 







































































已 经 成 功 地 等 待 了 所 有 子 进程 ， 没 有 子 进 程 的 退出 信息 需要 接收 ， 在 这 种 情况 下 ，wait〈) 函数 返回 -1，errno 为 ECHILD。 














《LinuxUnix 系 统 编程 手册 》 给 出 下 国 

















的 代码 来 等 待 所 有 子 进程 的 退出 : 











while((childqPid = wait (NULL)) != -1) 
continue; 

if(errno !=ECHILD) 
errExit ("wait"); 















































这 种 方法 并 不 完全 ， 因 为 这 里 忽略 了 wait 〈() 函数 被 信号 中 断 这 种 情况 ， 如 果 wait 〈) 函数 被 信号 中 断 ， 上 面 的 代码 并 不 能 成 功 地 等 待 所 有 


子 进程 退出 。 



























































若 将 上 面 的 wait〈) 函数 封装 一 下 ， 使 其 在 信号 中 断后 ， 自 动 重启 wait 就 完备 了 。 代 码 如 下 : 


























pid t r wait(int *stat loc) 
1 


int retval; 
while(((retval = wait(stat loc)) == -1 && 
(errno == EINTR)) 


7 
return retval; 


} 

while((childPid = r wait (NULL)) != -1) 
continue; 

If(errno != ECHILD) 

{ 
/*some error happened*/ 


. 

















如 果 父 进程 调用 
的 顺序 ) 。 











wait() 函数 时 ， 已 经 有 
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慌 
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上 且 都 处 于 僵 




















站 状态 ， 那 么 哪 




















个 子 进程 会 被 先 处 理 是 不 一 定 的 《〈 标 # 





























过 上 面 的 讨论 ， 可 以 看 出 wait () 函数 存在 一 定 的 














并 未 规定 处 理 


























定 让 


局 限 性 : 




















:不 能 等 待 特 定 的 子 进程 。 如 果 进 程 存在 
































个 子 进程 ， 而 它 只 想 球 








wait〈) 只 能 一 一 等 待 ， 通 过 查看 返 

















取 某 个 子 进程 的 退出 状态 ， 并 不 关心 其 他 子 进程 的 退出 状态 ， 此 时 





可 值 来 判断 是 否 为 关心 的 子 进程 。 















































进程 退出 ， wait () 只 能 阻 和 


塞 。 有 些 时 候 ， 



































不 需要 阻塞 等 待 ， 类 似 于 trywait 的 概念 。 




















仅仅 是 想 尝 试 获取 退出 子 进程 
wait( ) 函数 没有 提供 trywait 的 接 


wait 〈) 函数 只 能 发 现 子 进程 的 终止 事 


所 



































状态 ， 如 果 不 存在 子 进程 退出 就 立刻 返 区 











而 









































事件 ， 如 果子 进程 因 



































某 信号 而 停止 ， 或 者 停止 的 子 进程 收 到 SIGCONT 信 和 号 又 恢 这 
wait () 函数 是 无 法 获知 的 。 换 言 之 ，wait () 能 够 探知 子 进程 的 死亡 ， 却 不 能 探知 子 进程 的 昏迷 (暂停 ) ， 也 无 法 探知 子 进 
〈 恢 复 执行 ) 。 






































执行 ， 这 些 事件 





















































程 从 昏迷 中 苏 本 
1 于 

















上 述 三 个 缺点 的 存在 ， 所 以 Linux 又 引入 了 waitpid () 函数 。 


4.7.3 ”等待 子 进程 之 waitpid 〈 ) 


waitpid () 函数 接口 如 下 : 


#include <sys/wait.h> 
pid t waitpid(pid t pid, int *status, int options); 


先 说 说 waitpid () 与 wait () 函数 相同 的 地 方 : 











返回 值 的 含义 相同 ， 都 是 终止 子 进程 或 因 信 号 停止 或 因 信号 恢复 而 执行 的 子 进程 的 进程 ID。 














status 的 含义 相同 ， 都 是 用 来 记录 子 进 程 的 相关 事件 ， 后 面 一 节 将 会 详细 介绍 。 








接 下 来 介绍 waitpid() 函数 特有 的 功能 








其 第 一 个 参数 是 pid t 类 型 ， 有 了 此 值 ， 不 难看 出 waitpid 函 数 肯 定 具 备 了 精确 打击 的 能 力 。waitpid 
函数 可 以 明确 指定 要 等 待 哪 一 个 子 进程 的 退出 〈 以 及 停止 和 恢复 执行 ) 。 事 实 上 ， 扩 展 的 功能 不 仅仅 
如 此 : 





























-pid>0: 表示 等 竺 进程 也 为 pid 的 子 进程 ， 也 就 是 上 文 提 到 的 精确 打击 的 对 象 。 

















-pid 二 0: 表示 等 待 与 调用 进程 同一 个 进程 组 的 任意 子 进程 ;因为 子 进程 可 以 设置 自己 的 进程 组 ， 
所 以 菜 些 子 进程 不 一 定 和 父 进 程 归属 于 同一 个 进程 组 ， 这 样 的 子 进程 ，waitpid 函 数 就 怠 不 关心 了 






































-pid 二 -1: 表示 等 待 任意 子 进程 ， 同 wait 类 似 。waitpid (-1，&status，0) 与 wait (&status) 完全 等 


—、~ 
~ 
Er 


-pid 二 -1: 等 待 所 有 子 进 程 中 ， 进 程 组 与 pid 绝 对 值 相等 的 所 有 子 进程 。 











内 核 之 中 ，wait 函 数 和 waitpid 函 数 调 用 的 都 是 wait4 系 统 调用 。 下 面 是 wait4 系 统 调用 的 实现 。 函 数 
的 中 间 部 分 ， 根 据 pid 的 正 负 或 是 否 为 Oo 和 -1 来 定义 wait_opts 类 型 的 变量 wo， 后 面 会 根据 wo 来 控制 到 底 
关心 哪些 进程 的 事件 。 

















SYSCALL DEFINE4 (wait4, pid t, upid, int user *, stat addr, 
“ity options, struct rusage __ user A ru) 
{ 


struct wait opts wo; 
struct pid *pid = NULL; 
enum pid type type; 
long ret; 
if (options & ~ (WNOHANG |WUNTRACED |WCONTINUED | 
WNOTHREAD | WCLONE | WALL) ) 
return -EINVAL; Se 
if (upid == -1) 
type = PIDTYPE MAX;  /* 任 意 子 进程 





克 交 
else if (upid < 0) { 
type = PIDTYPE PGID; 
pid = find et _pid(- upid); 
} else if (upid == 0) { 
type = PIDTYPE PGID; 
pid = Yet : task - pid (current, PIDTYPE PGID); 
} else /* upid > 0 */ { 
type = PIDTYPE PID; 
pid = find get pid(upid); 





wo.wo_ type = types 

wo.wo pid = pid; 

wo .WO flags = options | WEXITED; 
wo.wo_ info = NULL; 

wo.wo_stat = stat addr; 


WO.wo_rusage = ru; 

ret = do wait(&wo); 

put pid(pid); 

/* avoid REGPARM breakage on x86: */ 

asmlinkage protect(4, ret, upid, stat addr, options, ru); 
Eetuwn Eet? 








可 以 看 到 ， 内 核 的 do_wait 函 数 会 根据 wait_opts 类 型 的 wo 变量 来 控制 到 底 在 等 竺 哪些 子 进程 的 状 


5 








当前 进程 中 的 每 一 个 线程 (在 内 核 层面 ， 线 程 就 是 进程 ， 每 个 线程 都 有 独立 的 task_struct〉 ， 都 会 
遍历 其 子 进程 。 在 内 核 中 ，task struct 中 的 children 成 员 变 量 是 个 链表 头 ， 该 进程 的 所 有 子 进程 都 会 链 入 
该 链表 ， 遍 历 起 来 比较 方便 。 代 码 如 下 : 

















static int do wait thread (Struct wait opts *xwo struct task struct *tsk) 
{ 


struct task Struct “ps 
list for each ,entry(p, &tsk->children, sibling) { 
/* 遍 历 进程 所 有 的 子 进程 


*/ 
int ret = wait consider task(wo, 0, p); 
if (ret) 
Leturn Eety 
} 


return 0; 





但 是 我 们 并 不 一 定 关心 所 有 的 子 进程 。 当 wait () 函数 或 waitpid () 函数 的 第 一 个 参数 pid 等 于 -1 
的 时 候 ， 表 示 任 意 子 进 程 我们 都 关心 。 但 是 如 果 是 waitpid 〈) 函数 的 其 他 情况 ， 则 表示 我 们 只 关心 其 
中 的 某 些 子 进程 或 某 个 子 进程 。 内 核 需要 对 所 有 的 子 进程 进行 过 滤 ， 找 到 关心 的 子 进程 。 这 个 过 滤 的 
环节 是 在 内 核 的 eligible pid 函数 中 完成 的 。 











/* 当 


Waitpigd 的 第 一 个 参数 为 


一 工时 ， 


WO->WO 七 YPe 赋值 为 


PIDTYPE MAX 
* 其 他 三 种 情况 


task pid type (p, wo->wo type)== wo->woO _ pid 检验 


* 或 者 检查 


pid 是 否 相 等 ， 或 者 检查 进程 组 


工 D 是 否 等 于 指定 值 


*/ 
static int eligible pidl(struct wait opts *wo, struct task struct *p) 
{ 
return WO->wo_ type == PIDTYPE MAX || 
task pid type(p, wo->wo type) == wo->wo pid; 
} 


waitpid 函 数 的 第 三 个 参数 options 是 一 个 位 掩 码 (bit mask) ， 可 以 同时 存在 多 个 标志 。 当 options 没 
有 设置 任何 标志 位 时 ， 其 行为 与 wait 类 似 ， 即 阻塞 等 待 与 pid 匹 配 的 子 进程 退出 。 











options 的 标志 位 可 以 是 如 下 标志 位 的 组 合 : 





`WUNTRACE: 除了 关心 终止 子 进程 的 信息 ， 也 关心 那些 因 信和 号 而 停止 的 子 进程 信息 。 























`WCONTINUED: 除了 关心 终止 子 进程 的 信息 ， 也 关心 那些 因 收 到 信和 号 而 恢复 执行 的 子 进程 的 状 


态 信息 











`WNOHANG: 指定 的 子 进程 并 未 发 生 状 态 变化 ， 立 刻 返 回 ， 不 会 阻塞 。 这 种 情况 下 返回 值 是 0。 
如 果 调 用 进程 并 没有 与 pid 匹 配 的 子 进程 ， 则 返回 -1， 并 设置 errno 为 ECHILD， 根 据 返 回 值 和 errno 可 以 
区 分 这 两 种 情况 。 


























传统 的 wait 函 数 只 关注 子 进程 的 终止 ， 而 waitpid 函 数 则 可 以 通过 前 两 个 标志 位 来 检测 子 进程 的 停止 
和 从 停止 中 恢复 这 两 个 事件 。 

















讲 到 这 里 ， 需 要 解释 一 下 什么 是 “使 进程 停止 >， 什 么 是 “使 进程 继续 "， 以 及 为 什么 需要 这 些 。 设 想 
如 下 的 场景 ， 正 在 某 机 器 上 编译 一 个 大 型 项 目 ， 编 译 过 程 需要 消耗 很 多 CPU 资源 和 磁盘 IO 资源 ， 并 且 
耗 时 很 入 。 如 果 我 暂时 需要 用 机 器 做 其 他 事情 ， 虽 然 可 能 只 需要 占用 几 分 钟 时 间 。 但 这 会 使 这 几 分钟 
内 的 用 户 体验 非常 糟糕 ， 那 怎么 办 ? 当然 ， 杀 掩 编译 进程 是 一 个 选择 ， 但 是 这 个 方案 并 不 好 。 因 为 编 
译 耗 时 很 久 ， 贸 然 杀 和 死 进程 ， 你 将 不 得 不 从 头 编译 起 。 这 时 候 ， 我 们 需要 的 仅仅 是 让 编译 大 型 工程 的 





























进程 停 下 来 ， 把 CPU 资源 和 IO 资源 让 给 我 ， 让 我 从 容 地 做 自己 想 做 的 事情 ， 几 分 钟 后 ， 我 用 完了 ， 让 
编译 的 进程 继续 工作 就 行 了 。 














Linux 提 供 了 SIGSTOP 〈 信 号 值 19) 和 SIGCONT (信号 值 18〉 两 个 信号 ， 来 完成 暂停 和 恢复 的 动 
作 ， 可 以 通过 执行 kill-SIGSTOP 或 kill-19 来 暂停 一 个 进程 的 执行 ， 通 过 执行 Kill-SIGCONT 或 Kill-18 来 让 
一 个 暂停 的 进程 恢复 执行 。 



































waitpid〈) 消 数 可 以 通过 WUNTRACE 标 志 位 关注 停止 的 事件 ， 如 果 有 子 进程 收 到 信号 处 于 暂停 状 
态 ，waitpid 就 可 以 返回 。 











同样 的 道理 ， 通 过 WCONTINUED 标 志 位 可 以 关注 恢复 执行 的 事件 ， 如 果 有 子 进 程 收 到 SIGCONT 信 
号 而 恢复 执行 ，waitpid 就 可 以 返回 。 














但 是 上 述 两 个 事件 和 子 进 程 的 终止 事件 是 并 列 的 关系 ，waitpid 成 功 返 回 的 时 候 ， 可 能 是 等 到 了 子 
进程 的 终止 事件 ， 也 可 能 是 等 到 了 暂停 或 恢复 执行 的 事件 。 这 需要 通过 status 的 值 来 区 分 。 

















那么 ， 现 在 应 该 分 析 status 的 值 了 。 


4.7.4 等 待 子 进程 之 等 待 状 态 值 


无 论 是 wait () 函数 还 是 waitpid() 函数 ， 都 有 一 


























息 。 如 果 不 为 空 ， 则 根据 填充 的 status 值 ， 可 以 获取 到 子 进程 的 很 多 信息 ， 如 图 4-12 所 示 。 


常 终止 


,被 信号 


图 4-12 ”wait 返 回 的 子 进程 的 状态 信息 

















根据 图 4-12 可 知 ， 直 接 根 据 status 值 可 C 
提供 了 相应 的 宏 (macro〉 ， 用 来 解析 返回 值 。 下 面 分 别 介 绍 各 种 情况 。 
















































































1. 进 程 是 正常 退出 的 








有 两 个 宏 与 正常 退出 相关 ， 见 表 4-4。 





个 status 变 量 。 这 个 变量 是 一 个 int 型 指针 。 可 以 传递 NULL， 表 示 不 关心 子 进程 的 状态 信 


内 核 转 储 ( core dumped ) 标志 








Ox7F 


不 应 该 直接 解析 status 值 来 获取 退 








以 获得 进程 的 退出 方式 ， 但 是 为 了 保证 可 移植 性 ， 

















表 4-4 与 进程 正常 退出 相关 的 宏 





沙 


WIFEXITED (status) 


WEXITSTATUS (status) 





























所 谓 截取 退出 状态 8~15 位 的 值 ， 也 就 是 exit_group 系 统 调用 用 





如 果子 进程 正常 退出 
如 果子 进程 正常 退出 ， 


说 


， 则 返回 true， 


明 


Ky 


。 因 此 系统 








状 


上 上 


否则 返回 false 


则 本 宏 用 来 获取 进程 的 退出 状态 


户 传 入 的 int 型 的 值 。 当 然 只 有 最 低 的 8 位 : 





#define __ WEXITSTATUS (status) (((status) & Oxff00) >> 8) 

















2. 进 程 收 到 信号 ， 导 致 退出 


有 三 个 宏 与 这 种 情况 相关 ， 见 表 4-5。 

















表 4-5 ”与 进程 收 到 信号 局 


沙 


WIFSIGNALED (status) 
WTREMSIG(status) 


WCOREDUMP(status) 














3. 进 程 收 到 信号 ， 被 停止 





有 两 个 宏 与 这 种 情况 相关 ， 见 表 4-6。 





至 退出 相关 的 宏 


说 


如 果 进 程 是 被 信号 "A 入 死 的 ， 
如 果 进 程 是 被 信号 杀 死 的 ， 


则 返回 true， 


则 返 


如 果子 进程 产生 了 core dump ， 


明 


否则 返回 false 


回 杀 死 进程 的 信号 = 的 值 


则 返回 true 


否则 返回 false 




















表 4-6 与 进程 收 到 信号 被 停止 相关 的 宏 


宏 说 明 
如 果子 进程 因 收 到 相关 信号 ， 和 暂停 执行 ， 处 于 停止 状态 ， 则 返回 true， 
WESTOEEEDUstatua 如 果 了 进程 因 收 到 相关 信号 ， 暂 停 执 行 ， 处 于 停止 状 则 返回 true 
否则 返回 fasle 
WSTOPSIG(status) 如 果子 进程 处 于 停止 状态 ， 这 个 宏 返 回 导 致 子 进程 停止 的 信号 的 值 
































之 所 以 需要 WSTOPSIG 宏 来 返回 导致 子 进程 停止 的 信号 值 ， 是 因为 不 只 一 个 信号 可 以 导致 子 进 程 停止 : SIGSTOP、SIGTSTP、SIGTTIN、 
SIGTTOU， 都 可 以 使 进程 停止 。 



































4. 子 进程 恢复 执行 


有 一 个 宏 与 这 种 情况 相关 ， 见 表 4-7。 














表 4-7 与 子 进程 恢复 执行 相关 的 宏 


沙 


说 明 


WIFCONTINUED(status) | 如 果 由 于 SIGCONT 信号 的 递送 ， 子 进程 恢复 执行 ， 则 返回 tue， 和 否则 返回 false 




































































为 何 没 有 返回 使 子 进程 恢复 的 信号 值 的 宏 ? 原因 是 只 有 SIGCONT 信 和 号 能 够 使 子 进程 从 停止 状态 中 恢复 过 来 。 如 果子 进程 恢复 执行 ， 只 可 能 
是 收 到 了 SIGCONT 信 号 ， 所 以 不 需要 宏 来 取信 号 的 值 。 






























































下 面 给 出 了 判断 子 进程 终止 的 示例 代码 。 等 待 子 进程 暂停 或 恢复 执行 的 情况 ， 可 以 根据 下 面 的 示例 代码 自行 实现 。 








void print wait exit(int status) 


printf("status = %d\n",status); 
if (WIFEXITED (status) ) 
. 
printf("normal termination,exit status = %d\n",WEXITSTATUS (status)); 


else if (WIFSIGNALED (status)) 
{ 
printf("abnormal termination,signal number =%d%s\n",WTERMSIG (status), 
#ifdef WCOREDUMP 
WCOREDUMP (status) ?"core file generated" : "")，; 
#else 
#endif 


} 











尽管 waitpid 函 数 对 wait 函 数 做 了 很 多 的 扩展 ， 但 waitpid 函 数 还 是 存在 不 足 之 处 ; 














waitpid 固 然 通 过 WUNTRACE 和 WCONTINUED 标 志 位 ， 增 加 了 对 子 进程 停止 事件 和 子 进 程 恢复 执行 事件 的 支持 ， 但 是 这 种 支持 并 不 完美 ， 这 
两 种 事件 都 和 子 进程 的 终止 事件 混在 一 起 了 。 






















































































wait 和 waitpid 函 数 都 会 调用 wait4 系 统 调 用 ， 无 论 用 户 传 递 的 参数 为 何 ， 总 会 添上 WEXITED 事 件 ， 如 下 所 示 : 














wo.wo_flags = options WEXITED; 


















































如 果 用 户 不 关心 子 进程 的 终止 事件 ， 只 关心 子 进程 的 停止 事件 ， 能 和 否 使 用 waitpid () 明确 做 到 ? 答案 是 不 行 。 
为 子 进 程 终止 ， 也 可 能 是 因为 子 进程 停止 。 这 是 waitpid 和 wait 的 致命 缺陷 。 


I 





waitpid 返 回 时 ， 可 能 是 因 


















































为 了 解决 这 个 缺陷 ，wait 家 族 的 最 重要 成 员 ，waitid〈) 函数 就 要 内 亮 登场 了 。 


4.7.5 ”等待 子 进程 之 waitid () 


前 面 提 到 过 ，waitpid 函 数 是 wait 函 数 的 超 集 ，wait 函 数 能 干 的 事情 ，waitpid 函 数 都 能 做 到 。 但 是 waitpid 函 数 的 控制 还 是 不 太 精 确 ， 无 论 用 户 
是 否 关心 相关 子 进程 的 终止 事件 ， 终 止 事件 都 可 能 会 返回 给 用 户 。 因 此 Linux 提 供 了 waitid 系 统 调 用 。glibc 封 装 了 waitid 系 统 调 用 从 而 实现 了 
waitid 函 数 。 尽 管 目前 普遍 使 用 的 是 wait 和 waitpid 两 个 函数 ， 但 是 waitid 函 数 的 设计 显然 更 加 合理 。 





























































































































be 

















waitid 函 数 的 接口 定义 如 








#include <sys/wait.h> 
int waitid(idtype t idtype, id t idq,siginfo t *infop, int options); 











该 函数 的 第 一 个 入 参 idtype 和 第 二 个 入 参 id 用 于 选择 用 户 关 心 的 子 进程 。 



































“idtype 一 P_PID: 精确 打击 ， 等 待 进程 ID 等 于 id 的 进程 。 











-idtype 一 P_PGID: 在 所 有 子 进 程 中 等 待 进程 组 ID 等 于 id 的 进程 。 























-idtype 一 P_ALL: 等 待 任意 子 进程 ， 第 二 个 参数 id 被 忽略 。 




















waitid 函 数 的 改进 在 于 第 四 个 参数 options 。options 参 数 是 下 面 标志 位 的 按 位 或 : 
































-WEXITED: 等 待 子 进程 的 终止 事件 。 














-WSTOPPED 等 待 被 信号 暂停 的 子 进程 事件 。 




















-WCONTINUED: 等 待 先前 被 暂停 ， 但 是 被 SIGCONT 信 号 恢复 执行 的 子 进 程 。 




















这 三 个 标志 位 互相 独立 ， 因 此 能 解决 waitpid 的 致命 缺陷 ， 两 个 函数 的 标志 位 关系 如 表 4-8 所 示 。 





表 4-8 waitpid 函 数 和 waitid 函 数 的 标志 位 关系 


waitpid 的 标志 位 等 价 的 waitid 的 标志 位 
WUNTRACED WEXITED | WSTOPPED 
WCONTINUCED WEXITED | WCONTINUED 


waitid 函 数 还 支持 其 他 的 标志 位 。 


























WNOHANG: 这 个 标志 位 是 老 相 识 了 ， 语 义 与 waitpid 一 致 ， 与 id 匹配 的 子 进 程 若 并 无 状态 信息 需要 返回 ， 则 不 阻塞 ， 立 刻 返 
0。 如 果 调 用 进程 并 无 子 进程 与 id 匹配 ， 则 返回 -1， 并 且 设 置 errno 为 ECHILD。 








ko 


， 返 回 值 是 

















































































































WNOWAIT: 这 个 标志 位 是 waitid 的 独门 绝技 ，waitpid 和 wait 函 数 都 不 支持 。 通 过 前 面 的 讨论 可 以 知道 wait 并 不 仅仅 是 获取 子 进程 的 状态 信 
息 ， 它 还 会 改变 子 进 程 的 状态 。 最 典型 的 是 子 进程 的 退出 。wait 函 数 返 回 之 前 ， 子 进程 处 于 僵尸 状态 ， 取 走 信息 之 后 ， 内 核 负 责 调用 release_task 
函数 来 将 僵尸 子 进程 的 最 后 残存 资源 释放 掉 ， 子 进程 彻底 消失 。WNOWAIT 标 志 位 指示 内 核 ， 只 负责 获取 信息 ， 不 要 改变 子 进程 的 状态 。 带 有 
WNOWAIT 标 志 位 调用 waitid 函 数 ， 稍 后 还 可 以 调用 wait 或 waitpid 或 waitid 再 次 获得 同样 的 信息 。 








































































































































































































































































































第 三 个 参数 infop 本 质 是 个 返回 值 ， 系 统 调用 负责 将 子 进程 的 相关 信息 填充 到 infop 指 向 的 结构 体 中 。 如 果 成 功 获取 到 信息 ， 下 面 的 字段 将 会 
被 填充 : 
































“si_pid: 子 进 程 的 进程 ID， 相 当 于 wait 和 waitpid 成 功 时 的 返回 值 。 









































“si_uid: 子 进 程 真正 的 用 户 ID。 

















“si_signo: 该 字段 总 被 填 成 SIGCHLD。 























“si_code: 指示 子 进程 发 生 的 事件 ， 该 字段 可 能 的 取 值 是 : 

















-CLD_EXIT 子 进程 正常 退出 ) 




















-CLD_KILLED〈 子 进程 被 信号 杀 死 ) 

















-CLD_DUMPED ( 子 进程 被 信号 杀 死 ， 并 且 产 生 了 core dump) 




















-CLD_STOPPED 〈 子 进程 被 信号 暂停 ) 














-CLD_CONTINUED “〈 子 进程 被 SIGCONT 信 和 号 恢复 执行 ) 














-CLD_TRAPPED〈 子 进程 被 跟踪 ) 


“si_status: status 值 的 语义 与 wait 函 数 及 waitpid 函 数 一 致 。 





对 于 六 











值 ， 在 两 种 情况 下 会 返回 0: 


[Gr 














成功 等 到 子 进程 的 变化 ， 并 取 回 相应 的 信息 。 





加 























“设置 了 WNOHANG 标 志 位 ， 并 且 子 进程 状态 无 变化 。 




















如 何 区 分 这 两 种 情况 呢 ? 



































I 








解决 的 方法 就 是 判断 返回 的 siginfo_t 结 构 体 中 的 si_pid， 如 果 是 因为 子 进程 的 状态 变化 而 导致 的 返回 ， 则 si_pid 必 不 等 于 0， 而 是 等 于 子 进程 
的 进程 ID; 若 子 进程 状态 没有 变化 ， 则 si_pid 等 于 0。 但 是 标准 并 没有 规定 ，waitid 函 数 负责 将 siginfo_t 结 构 体 的 内 容 清 零 ， 所 以 为 了 正确 区 分 这 
两 种 情况 ， 唯 一 安全 的 做 法 就 是 首先 将 siginfo_t 结 构 体 清 零 ， 返 回 后 ， 通 过 判断 si_pid 是 否 为 0 来 分 辨 这 两 种 情况 。 示 例 代 码 如 下 : 




























































































ke 














siginfo 七 info ; 
memset (&info, 0, sizeof (siginfo 七 ) ) 7 


if (waited (idtype, id, &info, options | WNOHANG) == -1) 
{ 
/* 发 生 错 误 
wf 
+ 
else if(info.si pid == 0) 


/* 子 进程 没有 发 生变 化 


Wi 
} 


Iae 


/* 若 有 子 进程 状态 发 生变 化 ， 则 进一步 处 理 之 





4.7.6 ”进程 退出 和 等 待 的 内 核实 现 














Linux 引 入 多 线程 之 后 ， 为 了 支持 进程 的 所 有 线程 能 够 整体 退出 ， 内 核 引 入 了 exit_group 系 统 调 用 。 对 于 进程 而 言 ， 无 论 是 调用 exit () 函 



























































数 、_exit () 函数 还 是 在 main 函 数 中 return， 最 终 都 会 调用 exit _ group 系统 调用 。 














对 于 















































单线 程 的 进程 ， 从 do_exit_group 直 接 调 用 do_exit 就 退出 了 。 但 是 对 于 多 线程 的 进程 ， 如 果 某 一 个 线程 调用 了 exit_group 系 统 调用 ， 那 么 
该 线程 在 调用 do_exit 之 前 ， 会 通过 zap_other_threads 函 数 ， 给 每 一 个 兄弟 线程 挂 上 一 个 SIGKILL 信 号 。 内 核 在 尝试 递送 信号 给 兄弟 进程 时 (通过 
get_signal_ to_deliver 函 数 ) ， 会 在 挂 起 信号 中 发 现 SIGKILL 信 和 号。 内 核 会 直接 调用 do_group_exit 函 数 让 该 线程 也 退出 〈 如 图 4-13 所 示 ) 过 


程 在 第 3 章 中 已 经 详细 分 析 过 了 


do group exit 


需要 通知 其 他 线程 
































































































































Y—> 


zap_other threads 


图 4-13 ”进程 

















出 流程 图 


癌 



































在 do_exit 函 数 中 ， 进 程 会 释放 几乎 所 有 的 资源 《文件 、 共 享 内 存 、 信 号 量 等 ) 。 该 进程 并 不 甘心 ， 因 为 它 还 有 两 桩 心愿 未 

































































FE 为 父 进 程 ， 它 可 能 还 有 子 进程 ， 进 程 退出 以 后 ， 将 来 谁 为 它 的 子 进 程 “ 收 性”。 












































“作为 子 进程 ， 它 需要 通知 它 的 父 进程 来 为 自己 “ 收 尸 ” 





























这 两 件 事情 是 由 exit_ notify 来 负责 完成 的 ， 具 体 来 说 forget original parent 函 数 和 do_notify parent 函 数 各 自负 



































事 ， 如 表 4-9 所 示 。 


/ 

局 
一 - 

Nihal 











表 4-9 ”exit_notify 中 两 个 函数 及 其 负责 的 事务 


浮 数 名 说 明 
forget original parent 负责 给 退出 进程 的 子 进程 寻找 新 的 父 进程 
do_notify parent 负责 通知 退出 进程 的 父 进程 












































forget_original_parent () ， 多 人 么 “悲伤 ”的 函数 名 。 顾 名 思 义 ， 该 函数 用 来 给 自己 的 子 进程 安排 新 的 父 进 程 


王 。 












































给 自己 的 子 进程 安排 新 的 父 进程 ， 细 分 下 来 ， 是 两 件 事情 : 





1) 为 子 进程 寻找 新 的 父 进程 。 














2) 将 子 进 程 的 父 进 程 设置 为 第 1) 步 中 找到 的 新 的 父 











芝 
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为 子 进程 寻找 父 进程 ， 是 由 find_new_reaper〈) 函数 完成 的 。 如 果 退 出 的 进程 是 多 线程 进程 ， 则 可 以 将 子 进程 托付 给 自己 的 兄弟 线程 。 如 果 

















没有 这 样 的 线程 

















， 就 “ 托 孤 ”给 init 进 程 。 


























为 自 



































己 的 子 进程 找到 新 的 父 杀 之 后 ， 内 核 会 遍历 退出 进程 的 所 有 子 进程 ， 将 新 的 父亲 设置 为 子 进程 的 父亲 。 




















static void forget original parent (struct task struct *father) 


‘ 


Btruct task struct “py *ns *reapers 
LIST HEAD(dead children); 
write lock irq(&tasklist lock); 


/* 


* Note that exit ptrace() and find new reaper() might 
* drop tasklist lock and reacquire it. 
*¥ 


exit ptrace (father); 


reaper = 


find new reaper (father); 


list for each entry safel(p, n, &father->children, sibling) { 


struct task struct *t = p; 
do 
t->real parent = reaper; 
if (t->parent == father) { 


和 
/* 内 核 提供 了 机 制 ， 允 许 父 进程 退出 时 向 子 进程 发 


wf 
if 


BUG_ ON (t->ptrace); 
t->parent = t->real parent; 





号 


(t->pdeath signal) 
group send sig info (t->pdeath signal， 
SEND_ SIG NOINFO, t); 


} while each thread(p, t); 
reparent leader (father, p, &dead children); 


} 


write unlock irq(&tasklist lock); 

BUG ON(!list empty (&father->children)); 

list for each entry safe(p, n, &dead children, sibling) { 
list del init (gp->sibling); 
release task(p); 


} 





这 部 分 代码 























比较 容易 引起 困扰 的 是 下 国 





























午 父 进程 “ 死 ” 的 时 候 向 子 进程 发 送信 号 。 











这 行 ， 我 们 都 知道 ， 子 进程 “ 死 * 的 时 候 ， 会 向 父 进程 发 送信 号 SIGCHLD，Linux 也 提供 了 一 种 机 制 ， 












































if (t->pdeath signal) 
group send sig info(t->pdeath signal, 
SEND_ SIG NOINFO, t); 
读者 可 以 通过 man prctl， 查 看 PR_SET_PDEATHSIG 标 志 位 部 分 。 如 果 应 用 程序 通过 prctl 函 数 设 置 了 父 进 程 “ 死 " 时 要 向 子 进程 发 送信 号 ， 就 

















会 执行 到 这 部 分 


接 下 来 是 第 








对 于 单线 程 
旺 终 止 的 时 候 ， 





为 什么 要 这 
儿子 ， 父 进程 也 






































内 核 代 码 ， 以 通知 其 子 进 程 。 























二 桩 未 了 的 心愿 : 想 办 法 通知 父 进程 为 自己 “ 收 尸 ”。 









































的 程序 来 说 完成 这 桩 心愿 比较 简单 ， 但 是 多 线程 的 情况 就 复杂 些 








。 只 有 线程 组 的 主线 程 才 有 资格 通知 父 进程 ， 线 程 组 的 其 他 线 



































不 需要 通知 父 进程 ， 也 没 必 要 保留 最 后 的 资源 并 陷入 僵尸 态 ， 直 























样 设计 ? 细 细 想来 ， 这 么 做 是 合理 的 。 父 进程 创建 子 进程 时 ， 只 有 子 进程 的 主线 程 是 父 进程 杀 自 
他 线程 ， 父 进程 压根 就 不 关心 。 



































只 关心 它 ， 至 于 子 进 程 调 





用 pthread_create 产 生 的 其 




















于 父 进程 


态 中 ， 主 线程 的 


























生命 在 于 “折腾 ”， 如 果 主 线程 率先 退出 了 ， 而 其 











jrelease task 函数 释放 所 有 资源 就 好 。 


调 















































创建 出 来 的 ， 是 父 进程 的 杀 台 


Vr 
































只 认 子 进程 的 主线 程 ， 所 以 在 线程 组 中 ， 主 线程 一 定 要 挺 住 。 在 























户 层面 ， 





可 以 调用 pthread_exit 让 主线 程 先 “ 死 "， 但 是 在 内 核 


























怕 变 成 僵尸 ， 也 不 能 释放 资源 。 


去 


task struct 一 定 要 挺 住 ， 表 





























他 线程 还 在 正常 工作 ， 内 核 又 将 如 何 处 理 ? 





else if (thread group leader (tsk)) { 


/* 线 程 组 组 


* 才 能 调用 


do_notify pare 


和 
autore. 
do _ not 
} else { 


长 只 有 在 全 部 线程 都 已 退出 的 情况 下 ， 


mt 通知 父 进程 


ap = thread group empty(tsk) && 
ify Parent (tsk, tsk->exit signal); 


/* 如 果 是 线程 组 的 非 组 长 线程 ， 可 以 立即 调用 


release task, 


* 释 放 残 余 的 资源 ， 因 为 通知 父 进 程 这 件 事 和 它 没 有 关系 


SA 


autoreap = true; 























上 面 的 代码 给 出 了 答案 ， 如 果 退 出 的 进程 是 线程 组 的 主线 程 ， 但 是 线程 组 中 还 有 其 他 线程 尚未 终止 〈thread_group_empty 函 数 返 回 false) ， 
那么 autoreaper 就 等 于 false， 也 就 不 会 调用 do_notify_parent 向 父 进程 发 送信 号 了 。 



















































































因为 子 进 程 的 线程 组 中 有 其 他 线程 还 活着 ， 因 此 子 进 程 的 主线 程 退 出 时 不 能 通知 父 进 程 ， 错 过 了 调用 do_notify parent 的 机 会 ， 那 么 父 进程 如 
何 才 能 知晓 子 进程 已 经 退出 了 呢 ? 答案 会 在 最 后 一 个 线程 退出 时 揭晓 。 此 答案 就 藏 在 内 核 的 release_task 函 数 中 : 
























































Jeader = p->group leader; 
if (leader != p && thread group empty (leader) && leader->exit state == EXIT ZOMBIE) { 
Zap_leader = do notify parent (leader, leader->exit signal); 
if (zap leader) 
leader->exit state = EXIT DEAD; 





当 线 程 组 的 最 后 一 个 线程 退出 时 ， 如 果 发 现 : 


该 线程 不 是 线程 组 的 主线 程 。 








:线程 组 的 主线 程 已 经 退出 ， 且 处 于 僵尸 状态 。 




















己 是 最 后 一 个 线程 。 


























同时 满足 这 三 个 条 件 的 时 候 ， 该 子 进程 就 需要 冒充 线程 组 的 组 长 ， 即 以 子 进程 的 主线 程 的 身份 来 通知 父 进 程 。 
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上 面 讨论 了 一 种 比较 少见 又 比较 折腾 的 场景 ， 正 常 的 多 线程 编程 应 该 不 会 如 此 安排 。 对 于 多 线程 的 进程 ， 一 般 情况 下 会 等 所 有 其 他 线程 退 
出 后 ， 主 线程 才 退 出 。 这 时 ， 主 线程 会 在 exit_ notify 函 数 中 发 现 自己 是 组 长 ， 线 程 组 里 所 有 成 员 均 已 退出 ， 然 后 它 调用 do_notify_parent 函 数 来 通 
知 父 进程 。 

































































无 论 怎 样 ， 子 进程 都 走 到 了 do_notify_parent 函 数 这 一 步 。 该 函数 是 完成 父子 进程 之 间 互 动 的 主要 函数 。 





bool do notify parent (struct task struct *tsk, int sig) 
1 
struct siginfo info; 
unsigned long flags; 
struct sighand struct *psig; 
bool autoreap = false; 
BUG ON (sig == -1)， 
/* do notify parent cldstop should have been called instead. */ 
BUG ON(task is _stopped : or traced (tsk)); 
BUG ON(!tsk->ptrace && 


(tsk->group leader != tsk || !thread group empty (tsk))); 
if (sig != SIGCHLD) { 
/六 
* This is only possible if parent == real parent., 
* Check if it has changed security domain. 
Wf 
if (tsk->parent exec id != tsk->parent->self exec id) 


sig = SIGCHLD; 
} 
info.si signo = sig; 
info.si errno = 0; 
rcu read lock!{(})s 
info.si pid = task pid nr ns(tsk, tsk->parent->nsproxy->pid ns); 
info.si uid = task cred(tsk)->uid; 
rcu read unlock(); 
info.si utime = cputime to clock t (cputime add (tsk->utime, 
tsk->signal-— >utime) )7 
info.si stime = cputime to clock t(cputime add (tsk->stime, 
tsk->signal-—. >stime)); 
info.si status = tsk->exit code & Ox7f; 
if (tsk->exit code & 0x80 
info.si code = CLD DUMPED; 
else if (tsk->exit code & 0x7f) 
info.si cogde = CLD KILLED; 
else { 和 a 
info.si code = CLD EXITED; 
info.si status = tsk->exit code >> 8; 
# 
psig = tsk->parent->sighang; 
spin lock _ irqsave (&psig- >siglock, flags); 
if (!tsk->ptrace && sig == SIGCHLD && 
(psig->action[SIGCHLD-1] .sa.sa handler == SIG IGN || 
(psig- >action[SIGCHLD-1] .sa.sa flags & SA_NOCLDWAIT) ) ) { 
autoreap = true; 
他 二 (Psig- >action[SIGCHLD-1] .sa.sa handler == SIG IGN) 
sig = 0; 


} 
/* 子 进程 向 父 进程 发 送信 号 


wy 
if (valiqd : signal (sig) && Sig) 
group send sig infol(sig, &info, tsk->parent); 
/* 子 进 程 尝试 唤醒 父 进程 ， 如 果 父 进程 正在 等 待 其 终止 


*/__ wake up Parent (tsk, tsk->parent); 
spin unlock irqrestore(&psig->siglock, flags); 
return autoreap; 




















父子 进程 之 间 的 互动 有 两 种 方式 : 











: 子 进程 向 父 进 程 发 送信 号 SIGCHLD。 

















: 子 进 程 唤醒 父 进程 。 






































对 于 这 两 种 方法 ， 我 们 分 别 展开 讨论 。 





1. 父 子 进程 互动 之 SIGCHLD 信 号 







































































父 进程 可 能 并 不 知道 子 进程 是 何 时 退出 的 ， 如 果 调 用 wait 函 数 等 待 子 进程 退出 ， 又 会 导致 父 进程 陷入 阻塞 ， 无 法 执行 其 他 任务 。 那 有 没有 




































































种 办 法 ， 让 子 进 程 退出 的 时 候 ， 有 异步 通知 到 父 进程 呢 ? 答案 是 肯定 的 。 当 子 进程 退出 时 ， 会 向 父 进程 发 送 SIGCHLD 信 和 号。 



























































父 进程 收 到 该 信号 ， 默 认 行为 是 置之不理 。 在 这 种 情况 下 ， 子 进程 就 会 陷入 僵尸 状态 ， 而 这 又 会 浪费 系统 资源 ， 该 状态 会 维持 到 父 进程 退 
出 ， 子 进程 被 initj 进 程 接 管 ，init 进 程 会 等 待 僵尸 进程 ， 使 僵尸 进程 释放 资源 。 














































































































如 果 父 进程 不 太 关心 子 进 程 的 退出 事件 ， 听 之 任 之 可 不 是 好 办 法 ， 可 以 采取 以 下 办 法 : 




















: 父 进程 调用 signal 函 数 或 sigaction 函 数 ， 将 SIGCHLD 信 和 号 的 处 理 函 数 设置 为 SIG_IGN。 























上 


- 父 进程 调用 sigaction 函 数 ， 设 置 标志 位 时 置 上 SA _NOCLDWAIT 位 (如 果 不 关 心 子 进程 的 暂停 和 恢复 执行 ， 则 置 上 SA _NOCLDSTOP 位 〉。 

































































从 内 核 代码 来 看 ， 如 果 父 进程 的 SIGCHLD 的 信号 处 理 函 数 为 SIG_IGN 或 sa_flags 中 被 置 上 了 SA_NOCLDWAIT 位 ， 子 进程 运行 到 此 处 时 就 知道 





















































了 ， 父 进程 并 不 关心 自己 的 退出 信息 ，do_notify_parent 函 数 就 会 返回 true。 在 外 层 的 exit_ notify 函 数 发 现 返回 值 是 true， 就 会 调用 release_task 函 
数 ， 释 放 残 余 的 资源 ， 自 行 了 断 ， 子 进程 也 就 不 会 进入 僵尸 状态 了 。 




































































如 果 父 进程 关心 子 进程 的 退出 ， 情 况 就 不 同 了 。 父 进程 除了 调用 wait 函 数 之 外 ， 还 有 了 另外 的 选择 ， 即 注册 SIGCHLD 信 号 处 理 函 数 ， 在 信 
号 处 理 函 数 中 处 理子 进程 的 退出 事件 。 















































为 SIGCHLD 写 信号 处 理 函 数 并 不 简单 ， 原 因 是 SIGCHLD 是 传统 的 不 可 靠 信号 。 信 号 处 理 函数 执行 期 间 ， 会 将 引发 调用 的 信号 暂时 阻塞 〈 除 
非 显 式 地 指定 了 SA_NODEFER 标 志 位 ) ， 在 这 期 间 收 到 的 SIGCHLD 之 类 的 传统 信号 ， 都 不 会 排队 。 因 此 ， 如 果 在 处 理 SIGCHLD 信 号 时 ， 有 多 个 
子 进程 退出 ， 产 生 了 多 个 SIGCHLD 信 和 号， 但 父 进 程 只 能 收 到 一 个 。 如 果 在 信号 处 理 函 数 中 ， 只 调用 一 次 wait 或 waitpid， 则 会 造成 某 些 僵尸 进程 
成 为 漏网 之 鱼 。 



































































































































Ea 





正确 的 写法 是 ， 信 号 处 理 函 数 内 ， 带 着 NOHANG 标 志 位 循环 调用 waitpid。 如 果 返 

















值 大 于 0， 则 表示 不 断 等 待 子 进 程 退出 ， 返 回 0 则 表示 ， 
当前 没有 僵尸 子 进程 ， 返 回 -1 则 表示 出 错 ， 最 大 的 可 能 就 是 errno 等 于 ECHLD， 表 示 所 有 子 进 程 都 已 退出 。 






























































while (waitpid(-1,&status,WNOHANG) > 0) 


/* 此 处 处 理 返回 信息 


sf 
continue; 


} 



































言 号 处 理 函数 中 的 waitpid 可 能 会 失败 ， 从 而 改变 全 局 的 errno 的 值 ， 当 主 程序 检查 errno 时 ， 就 有 可 能 发 生 神 突 ， 所 以 进入 信号 处 理 函 数 前 要 
现 保存 errmo 到 本 地 变量 ， 信 号 处 理 函 数 退 出 前 ， 再 恢复 errno。 



































2. 父 子 进程 互动 之 等 待 队列 










































































上 一 种 方法 可 以 称 之 为 信号 通知 。 另 一 种 情况 是 父 进程 调用 wait 主 动 等 待 。 如 果 父 进程 调用 wait 陷 入 阻塞 ， 那 么 子 进程 退出 时 ， 又 该 如 何 及 
时 唤醒 父 进程 呢 ? 







































































前 面 提 到 了 ， 子 进程 会 调用 _wake_up_parent 函 数 ， 来 及 时 唤醒 父 进程 。 事 实 上 ， 前 提 条 件 是 父 进程 确实 在 等 待 子 进 程 的 退出 。 如 果 父 进程 
jwait 系 列 函 数 等 待 子 进程 的 退出 ， 那 么 ， 等 待 队 列 为 空 ， 子 进程 的 _wake_up_parent 对 父 进程 并 无 任何 影响 。 
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void _ wake up parent (struct task struct *p, struct task struct *parent) 
, 
_ wake up sync key (&parent->signal->wait chldexit, 
TASK_INTERRUPTIBLE, 1, p); 

















5 














父 进程 的 进程 描述 符 的 signal 结 构 体 中 有 wait_childexit 变 量 ， 这 个 变量 是 等 待 队列 头 。 父 进程 调用 wait 系 列 函 数 时 ， 会 创建 一 个 wait_opfs 结 构 


体 ， 并 把 该 结构 体 挂 入 等 待 队列 中 。 





UD 














static long do wait(struct wait opts *wo) 
{ 
struct task struct *tsk; 
int retval; 
trace_ sched process wait (wo->wo pid); 
/* 挂 入 等 待 队列 


/ 

init waitqueue func entry(&wo->child wait, child wait callback); 

wo->child wait.private = current; 本 去 

add wait queue (&current->signal->wait Chldexit, &wo->child wait); 
repeat: 加 加 

pew 

wo->notask error = -ECHILD; 

i£ ( (wo->wo_type < PIDTYPE MAX) && 


(!wo->wo pid || hlist empty(&wo->wo pid->tasks [wo->wo typel]))) 
goto notask; 加 
set current state (TASK INTERRUPTIBLE) 
read lock (gtasklist lock); 
tsk = current; 
de 1 
retval = do wait thread (wo, tsk); 
if (retval) 加 
goto end; 
retval = ptrace do wait (wo, tsk); 
if (retval) 
goto end; 
if (wo->wo_ flags & _ WNOTHREAD) 
break; 
} while each thread(current, tsk); 
read unlock (&tasklist lock); 
/* 找 了 一 圈 ， 没 有 找到 满足 等 待 条 件 的 的 子 进程 ， 下 一 步 的 行为 将 取决 于 


WNOHANG 标 志 位 


* 如 果 将 


WNOHANG 标 志 位 置 位 ， 则 表示 不 等 了 ， 直 接 退 出 ， 


* 如 果 没 有 置 位 ， 则 让 出 


CPU， 醒 来 后 继续 再 找 一 圈 


®y 
notask: 
retval = wo->notask error; 
if (!retval && ! (wo->wo flags & WNOHANG)) { 
retval = -ERESTARTSYS; 
if (!signal pending(current)) { 
schedule (); 
goto repeat; 
} 
} 
mds 


_ set current state (TASK RUNNING); 
remove wait queue(&current->signal->wait chldexit, &wo->child wait); 
return retval; 





























父 进 程 先 把 自己 设置 成 TASK_INTERRUPTIBLE 状 态 ， 然 后 开始 寻找 满足 等 待 条 件 的 子 进程 。 如 果 找 到 了 ， 则 将 自己 重 置 成 
TASK_RUNNING 状 态 ， 欢 乐 返 回 :， 如 果 没 找到 ， 就 要 根据 WNOHANG 标 志 位 来 决定 等 不 等 待 子 进程 。 如 果 没 有 WNOHANG 标 志 位 ， 那 么 ， 父 进 
程 就 会 让 出 CPU 资源 ， 等 待 别人 将 它 唤 醒 。 















































ad 












































I 




















到 男 一 头 ， 子 进程 退出 的 时 候 ， 会 调用 wake_up_parent， 唤 醒 父 进程 ， 父 进程 醒 来 以 后 ， 回 到 repeat， 再 次 扫描 。 这 样 做 ， 子 进程 的 退 
出 就 能 及 时 通知 到 父 进 程 ， 从 而 使 父 进程 的 wait 系 列 函 数 可 以 及 时 返 
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4.8 ”exec 家 族 








前 面 讨论 了 进程 的 创建 和 退出 ，exec 家 族 函 数 在 其 中 犹 抱 项 一半 遮 面 ， 现 在 是 时 候 让 exec 家 族 函 数 


登台 亮相 了 。 


议 


了 


整个 exec 家 族 有 6 个 函数 ， 这 些 函 数 都 是 构建 在 execve 系 统 调用 之 上 的 。 该 系统 调用 的 作用 是 ， 将 
新 程序 加 载 到 进程 的 地 址 空间 ， 丢 弃 旧 有 的 程序 ， 进 程 的 栈 、 数 据 段 、 堆 栈 等 会 被 新 程序 蔡 换 。 























基于 execve 系 统 调 用 的 6 个 exec 函 数 ， 接 口 虽 然 各 异 ， 实 现 的 功能 却 是 相同 的 ， 首 先 我 们 来 讲述 与 
系统 调用 同名 的 execve 函 数 。 


4.8.1 execve 函 数 


execve 函 数 的 接口 定义 如 下 : 


#include <unistd.h> 
int execve (Const char *filename, char *const argv[]， 
char *const envp[]); 


其 中 ， 参 数 flename 是 准备 执行 的 新 程序 的 路 径 名 ， 可 以 是 绝对 路 径 ， 也 可 以 是 相对 于 当前 工作 目 
录 的 相对 路 径 。 


后 面 的 第 二 个 参数 很 容易 让 我 们 联想 到 C 语 言 的 main《〈) 函数 的 第 二 个 参数 ， 事 实 上 格式 也 是 一 样 
的 : 字符 串 指针 组 成 的 数组 ， 以 NULL 结 束 。argv[0] 一 般 对 应 可 执行 文件 的 文件 名 ， 也 就 是 flename 中 的 
basename〈 路 径 名 最 后 一 个 /后 面 的 部 分 ) 。 当 然 如 果 argv[0] 不 遵循 这 个 约定 也 无 妨 ， 因 为 execve 可 以 
从 第 一 个 参数 获取 到 要 执行 文件 的 路 径 ， 只 要 不 是 NULL 即 可 。 














第 三 个 参数 与 C 语 言 的 main 函 数 中 的 第 三 个 参数 envp 一 样 ， 也 是 字符 串 指 针 数 组 ， 以 NULL 结 束 ， 
间 针 指向 的 字符 串 的 格式 为 name=value。 

















一 般 来 说 ，execve 〈) 函数 总 是 紧 随 fork 疯 数 之 后 。 父 进程 调用 fork 之 后 ， 子 进程 执行 execve 函 数 ， 
抛弃 父 进 程 的 程序 段 ， 和 父 进程 分 道 扬 镶 ， 从 此 天 各 一 方 ， 各 走 各 路 。 但 是 也 可 以 不 执行 fork， 单 独 调 
用 execve 函 数 ; 











#include <unistd.h> 
#include <stdlib.h> 
#include <stdio.h> 
int main (void) 
{ 
char *args[] = {"/bin/ls", "=1™",NULL}; 
if(execve("/bin/ls",args, NULL) == -1) { 
perror ("execve"); 
exit (EXIT FAILURE) 站 
} 
puts ("Never get here"); 
exit (EXIT SUCCESS); 








本 着 “ 贵 在 折腾 ”的 原则 ， 上 面 写 了 一 个 不 fork 直 接 调 用 execve 的 程序 。 调 用 execve 后 ， 程 序 就 变 成 
了 /binsh-1。 这 个 程序 的 输出 如 下 : 








total 16 
-rwxr-xr-x 1 root root 8672 Dec 27 20:40 exec no fork 
-LW-r-~r-~ 1 root root 288 Dec 27 20:40 exec no fork.c 


我 们 可 以 看 到 ， 代 码 段 最 后 的 Never get here 没 有 被 打印 出 来 ， 这 是 因为 execve 函 数 的 返回 是 特殊 
的 。 如 果 失 败 ， 则 会 返回 -1， 但 是 如 果 成 功 ， 则 永 不 返回 ， 这 是 可 以 理解 的 。execve 做 的 就 是 斩 断 过 
去 ， 奔 向 新 生活 的 事情 ， 如 果 成 功 ， 自 然 不 可 能 再 返回 来 ， 再 次 执行 老 程序 的 代码 。 





























所 以 无 须 检 查 execve 的 返回 值 ， 只 要 返回 ， 就 必然 是 -1。 可 以 从 errmo 判 断 出 出 错 的 原因 。 出 错 的 可 
能 性 非常 多 ， 手 册 提 供 了 19 种 不 同 的 errno， 罗 列 了 22 种 失败 的 情景 。 很 难 记 住 ， 好 在 大 部 分 都 不 各 
见 ， 和 常见 的 情况 有 以 下 儿 种 : 






































-EACCESS: 这 个 是 我 们 最 容易 想到 的 ， 就 是 第 一 个 参数 flename， 不 是 个 普通 文件 ， 或 者 该 文件 
没有 赋予 可 执行 的 权限 ， 或 者 目录 结构 中 某 一 级 目录 不 可 搜索 ， 或 者 文件 所 在 的 文件 系统 是 以 
MS_NOEXEC 标 志 挂 载 的 。 


























.ENOENT: 文件 不 存在 。 








:ETXTBSY: 存在 其 他 进程 尝试 修改 filename 所 指 代 的 文件 。 

















:ENOEXEC: 这 个 错误 其 实 是 比较 高 端的 一 种 错误 了 ， 文 件 存在 ， 也 可 以 执行 ， 但 是 无 法 执行 ， 
比如 说 ，Windows 下 的 可 执行 程序 ， 拿 到 Linux 下 ， 调 用 execve 来 执行 ， 文 件 的 格式 不 对 ， 就 会 返回 这 种 


世 、 品 
日 天 。 





上 面 提 到 的 ENOEXEC 错 误 码 ， 其 实 已 经 触及 了 execve 函 数 的 核心 ， 即 哪些 文件 是 可 以 执行 
的 ，execve 系 统 调 用 又 是 如 何 执行 的 呢 ? 这 些 会 在 execve 系 统 调 用 的 内 核 系 统 调 用 中 详细 介绍 。 


4.8.2 exec 家 族 














从 内 核 的 角度 来 说 ， 提 供 execve 系 统 i 



































:第 一 个 参数 必须 是 绝对 路 径 或 是 相对 














:execve 国 数 的 第 三 个 参数 是 环境 变量 指针 数组 ， 

















于 当前 工作 目录 的 相对 路 径 。 习 惯 大 
mkdir 之 类 命令 的 ， 没 有 人 会 写 /bimls 或 /bin/mkdir。shell 提 供 了 环境 变量 PATH， 即 可 执行 程序 的 


我 们 不 必 写 出 完整 的 路 径 ， 很 方便 ， 而 execve 函 数 享受 不 到 这 个 福利 ， 因 此 使 用 不 便 。 


















































Eshell 下 

















用 就 足够 了 ， 但 是 从 应 用 层 编程 的 角度 来 讲 ，execve 函 数 就 并 不 那么 好 使 了 : 





户 会 觉得 不 太 方便 ， 因 为 日 常 工作 都 是 写 1s 和 
































找 路 径 ， 对 于 位 于 查找 路 径 里 的 可 执行 程序 ， 




































































目 户 使 



































下 并 不 需要 定制 环境 变量 ， 只 需要 使 用 当前 的 环境 变量 即 可 。 



































正 是 为 了 提供 相应 的 便利 ， 所 以 用 户 层 提供 了 6 个 函数 ， 当 然 ， 这 些 函数 本 质 上 都 是 调 


如 下 : 








jexecve 编 程 时 不 得 不 自己 负责 环境 变量 





量 的 “key=value”， 但 大 部 分 情况 









































崩 execve 系 统 调 月 











目的 方法 略 有 不 同 ， 代 码 








#include <unistd.h> 
extern char **environ; 


int execl (const char *path, const char *arg, ...); 
int execlp (const char *file, const char *arg, 。.)? 
int execle (Const char *path, const char *arg, 

..， Char * const envp[]); 
int execv(const char *path, char *const argv[]); 
int execvp (const char *file, char *const argv[] 
int execve (const char *path, char *const argv[] 


char *const envp[]); 








IN 


上 述 6 个 函数 分 成 上 下 两 个 
有 的 参数 ， 下 半 区 采用 数组 。 





























区 。 分 类 的 依据 是 参 



































列表 〈1， 表 示 1list) 还 是 数组 (v， 表 示 vector) 。 上 半 














采用 列表 ， 它 们 会 罗列 所 






































execl 列表 
execlp 列表 
eXecV 数组 
execvp 数 

execve 数组 


举 个 例子 来 加 深 记 忆 : 








在 每 个 半 区 之 中 ， 带 p 的 表示 可 以 使 用 环境 变量 PATH， 
































表 4-10 ”exec 家 族 函 数 


是 否 自动 搜索 PATH 











带 e 的 表示 必须 要 自己 维护 环境 变量 ， 而 不 使 

















具体 见 表 4-10。 





< 





须 自 己 组 装 环境 变量 





#include <unistd.h> 
Char *const ps argv[] = {"ps","-ax",NULL}; 


char *const ps envp[] = {"PATH=/bin:/usr/bin","TERM=console",NULL}; 


execl ("/bin/ps", "ps","-ax",NULL); 
/# 带 


了 P 的 ， 可 以 使 用 环境 变量 
PATH， 无 须 写 全 路 径 


Wy 
execlp ("ps", "ps","-ax",NULL 
/* 带 


? 


Ee 的 需要 自己 组 拼 环 境 变量 


execle("/bin/ps", "ps","-ax",NULL,ps_envp); 
execv ("/bin/ps",ps_ argv); 


/+* 带 


PP 的 ， 可 以 使 用 环境 变量 


PATH,， 无须 写 全 路 径 


Wy 

execvp ("ps",ps argv); 
/* 带 

的 需要 自己 组 拼 环 境 变量 

Wy 


execve ("/bin/ps",ps_argv,ps_envp); 





4.8.3 ”execve 系 统 调 用 的 内 核实 现 

















前 面 提 到 的 ENOEXEC 错 误 表 示 内 核 不 知道 如 何 执 行 对 应 的 可 执行 文件 。Linux 支 持 很 多 种 可 执行 文件 的 格式 ， 有 渐渐 
退出 历史 舞台 的 a.out 格 式 ， 有 比较 通用 的 ELF 格 式 的 文件 ， 还 有 shell 脚 本 文件 、python 脚 本 、java 文 件 、php 文 件 等 。 对 于 
这 些 形形色色 的 可 执行 文件 ， 内 核 该 如 何 正 确 地 执行 昵 ? 直接 将 Windows 平 台 上 的 可 执行 文件 拷贝 到 Linux 下 ，Linux 为 什么 
不 能 执行 《假设 没有 wine 这 个 执行 Windows 程 序 的 工具 ) ? 这 是 本 节 需 要 解决 问题 。 要 解决 上 述 问题 ， 首 先 还 是 需要 深入 
内 核 。 
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execve 是 平台 相关 的 系统 调用 ， 刨 去 我 们 不 太 关 心 的 平台 差异 ， 内 核 都 会 走 到 do_execve_common 函 数 这 一 步 。 











static int do execve common(const char *filename, 
struct user arg ptr argyv, 
struct user arg ptr envp, 
struct pt regs *regs) 


struct linux binprm *bprm; 
struct file *file; 
struct files struct *displaced; 
bool clear in exec; 
int retval; 
const struct cred *ered = current cred!{); 
if ((current->flags & PF NPROC EXCEEDED) && 
atomic read(&cred->user->processes) > rlimit (RLIMIT NPROC)) { 
retval = -EAGAIN; 
goto out ret; 
} 
/* We're below the limit (still or again), so we don't want to make 
* further execve() calls fail. */ 
current->flags &= ~PF_ NPROC EXCEEDED; 
retval = unshare files(&displaced); 
if (retval) 
goto out ret; 
retval = -ENOMEM; 
bprm = kzalloc (sizeof (*bprm), GFP KERNEL); 
if (!bprm) 
goto out files; 
retval = prepare bprm creds (bprm); 
if (retval) 
goto out free; 
retval = check unsafe exec (bprm); 
if (retval < 0) 
goto out free; 
clear in exec = retval; 
current->in execve = 1; 
/* 读 取 可 执行 文件 





/ 
file = open_exec (filename); 
retval = PTR ERR(file); 
if (IS ERR(file)) 
goto out unmark; 
/* 选 择 负 载 最 小 的 
CPU 来 执行 新 程序 
wy 


sched exec (); 
bprm->file = file; 
bprm->filename = filename; 
bprm->interp = filename; 
retval = bprm mm init (bprm); 
if (retval) 
goto out file; 
bprm->argc = count (argv, MAX ARG STRINGS); 
if ((retval = bprm->argc) < 0) 
goto out; 
bprm->envce = Count (envp, MAX ARG STRINGS); 
if ((retval = bprm->envc) < 0) 
goto out;/* 填 充 


linux _bjinprm 数 据 结 构 


大 
/ 
retval = prepare binprm(bprm); 
if (retval < 0) 
goto out; 
/* 接 下 来 的 


Copy 用 来 拷贝 文件 名 、 命 令 行 参数 和 环境 变量 


«yf 


retval = copy strings kernel(1l, &bprm->filename, bprm); 


if (retval < 0) 
goto out; 
bprm->exec = bprm->p; 


retval = copy strings (bprm->envce, envp, bprm); 


if (retval < 0) 
goto out; 


retval = copy _ strings (bprm->argc, argv, bprm); 


if (retval < 0) 
goto out; 
/* 核 心 部 分 ， 遍历 





format ss 链表， 尝试 每 个 


load binary 函 数 


*/retval = search binary handler (bprm, regs); 


if (retval < 0) 

goto out; 
/* execve succeeded */ 
current->fs->in exec = 0; 
current->in execve = 0; 
acct update integrals (current); 
free bprm (bprm); 
if (displaced) 

put files struct (displaced); 
return retval; 


out: 
if (bprm->mm) { 
acct arg size (bprm, 0); 
mmput (bprm->mm); 
} 
out file: 


if (bprm->file) { 
allow write access (bprm->file); 
fput (bprm->file); 
} 
out unmark: 
if (clear in exec) 
current->fs->in exec = 0; 
current->in execve = 0; 
cut Eree: 
free bprm (bprm); 
out files: 
if (displaced) 
reset files struct (displaced); 
out ret: 
“return retval; 


} 





其 中 ，linux_binprm 是 重要 的 结构 体 ， 它 与 稍 后 提 到 的 linux_binfimt 联 手 ， 支 持 了 Linux 下 多 种 可 执行 文件 的 格式 。 首 











先 ， 内 核 会 将 程序 运行 需要 的 参数 argv 和 环境 变量 搜集 到 linux_binprm 结 构 体 中 ， 比 较 关 键 的 一 步 是 : 





retval = prepare _ pinprm (bprm); 








在 prepare_binprm 函 数 中 读 取 可 执行 文 伯 





的 头 128 个 字 节 ， 存 放 在 linux_ binprm 结 构 体 的 puffBINPRM_BUF SIZE] 中 。 我 








们 知道 日 常 写 shell 脚 本 、python 肢 本 的 时 候 ， 总 是 会 在 第 一 行 写 下 如 下 语句 : 








# 

/bin/bash 

#! /usr/bin/python 
# 


/usr/bin/env Python 





开头 的 #! 被 称 为 shebang， 又 被 称 为 sha-bang、hashbang 等 ， 指 的 就 是 脚本 中 开始 的 字符 。 在 类 Unix 操 作 系统 中 ， 运 行 
这 种 程序 ， 需 要 相应 的 解释 器 。 使 用 哪 种 解释 器 ， 取 决 于 shebang 后 面 的 路 径 。#1! 后 面 跟随 的 一 般 是 解释 器 的 绝对 路 径 ， 
或 者 是 相对 于 当前 工作 目录 的 相对 路 径 。 格 式 如 下 所 示 : 









































#! interpreter [optional-arg] 








解释 器 是 绝对 路 径 或 是 相对 于 当前 工作 目录 的 相对 路 径 ， 这 就 给 脚本 的 可 移植 性 带 来 了 挑战 。 以 python 的 解释 器 为 
例 ，python 可 能 位 于 /usrbin/python， 也 可 能 位 于 /usrlocalbin/python， 甚 至 有 的 还 位 于 /home/username/bin/python。 这 样 编写 
的 脚本 在 新 的 环境 里 面 运行 时 ， 用 户 就 不 得 不 修改 脚本 了 ， 当 大 量 的 脚本 移植 到 新 环境 中 运行 时 ， 修 改 量 是 巨大 的 。 为 了 
解决 这 个 问题 ， 系 统 又 引入 了 如 下 格式 : 









































/usr/bin/env Python 





在 执行 时 ， 这 种 格式 会 从 环境 变量 $PATH 中 查找 python 解 释 器 。 如 果 存 在 多 个 版 本 的 解释 器 ， 则 会 按照 SPATH 中 查找 
路 径 的 顺序 来 查找 。 











manu@manu-hacks 


~$ echo $PATH 
/home/manu/bin:/usr/local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games 





如 果 执 行 方式 是 ./python_script 的 方式 ， 就 会 优先 查找 /home/manuwbin/python，/usrlocalbin/python 次 之 .……… 如 下 所 示 : 





execve ("/home/manu/bin/python", ["python", "./hello.py"], [/* 25 vars */]) = -1 ENOENT (No such file or directory) 
execve("/usr/local/bin/python", ["python", "./hello.py"], [/* 25 vars */]) = -1 ENOENT (No such file or directory) 
execve ("/usr/local/sbin/python", ["python", "./hello.py"], [/* 25 vars */]) = -1 ENOENT (No such file or directory) 
execve ("/usr/local/bin/python", ["python", "./hello.py"], [/* 25 vars */]) = -1 ENOENT (No such file or directory) 
execve ("/usr/sbin/python", ["python", "./hello.py"], [/* 25 vars */]) = -1 ENOENT (No such file or directory) 
execve ("/usr/bin/python", ["python", "./hello.py"], [/* 25 vars */]) = 0 














上 面 提 到 的 是 脚本 文件 ， 除 此 以 外 ， 还 有 其 他 格式 的 文件 。Linux 平 台 上 最 主要 的 可 执行 文件 格式 是 ELF 格 式 ， 当 然 还 
有 出 现 较 早 ， 逐 渐 退 出 历史 舞台 的 的 a.out 格 式 ， 这 些 文件 的 特点 是 最 初 的 128 字 节 中 都 包含 了 可 执行 文件 的 属性 的 重要 信 
息 。 比 如 图 4-14 中 ELF 格 式 的 可 执行 文件 ， 开 头 4 字 节 为 7TF 45 (E) 4C (L) 46 (CF) 。 


























manu@manu-hacks 


~$ file hello 
hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked 
(uses shared libs), for GNU/Linux 2.6.24, BuildID[shal]=657d5ef3eab6741481bb219ef6c2fb21f8e91b51, not stripped 





hello 
0000 0000: 7F 45 4C 46 02 01 01 00 





0000 0010， 02 0 [0 3E 00 01 00 00 00 


四 





图 4-14 ELF 文 件 的 头 部 信息 








ptrepare_binprm 函 数 将 文件 开始 的 128 字 节 存 入 linux binprm， 是 为 了 让 后 面 的 程序 根据 文件 开头 的 magic number 选 择 正 
确 的 处 理 方式 。 























做 完 准 备 工 作 后 ， 开 始 执行 ， 核 心 代 码 位 于 search binary handler 〈) 函数 中 。 内 核 之 中 存在 一 个 全 局 链表 ， 名 叫 
formats， 挂 到 此 链表 的 数据 结构 为 struct linux_binfimt: 


























struct linux binfmt { 
struct list head lh; 
struct module *module; 
int (*load binary) (struct linux binprm *, struct pt regs * regs); 
int (*load shlib) (struct file *); 
int (*core -Aump) (struct coredump params *cPrrm) ， 
unsigned long min coredump; /* minimal dump size */ 





























操作 系统 启动 的 时 候 ， 每 个 编译 进 内 核 的 可 执行 文件 的 “代理 人 "都 会 调用 register_binfmt 函 数 来 注册 ， 把 自己 挂 到 
formats 链 表 中 。 每 个 成 员 代 表 一 种 可 执行 文件 的 代理 人 ， 前 面 提 到 过 ， 会 将 可 执行 文件 的 头 128 字 节 存 放 到 linux_binprm 的 
buf 中 ， 同 时 会 将 运行 时 的 参数 和 环境 变量 也 存放 到 linux binprm 的 相关 结构 中 。formats 链 表 中 的 成 员 依次 前 来 认领 ， 如 果 
是 自己 代表 的 可 执行 文件 的 格式 ， 后 面 执行 的 事情 ， 就 委托 给 了 该 “代理 人 ”。 
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rr 







































































如 果 遍 历 了 链表 ， 所 有 的 linux_binfmt 都 表示 不 认识 该 可 执行 文件 ， 那 又 当 如 何 呢 ? 这 种 情况 要 根据 头 部 的 信息 ， 查 看 
是 否 有 为 该 格式 设计 的 ， 作 为 可 动态 安装 的 模块 实现 的 “代理 人 ”存在 。 如 果 有 的 话 ， 就 把 该 模块 安装 进来 ， 挂 入 全 局 的 
formats 链 表 之 中 ， 然 后 让 formats 链 表 中 的 所 有 成 员 再 试 一 次 。 

































































述 逻 辑 位 于 search binary handler 函 数 之 中 : 





int search binary handqler (Struct linux binprm *bprm,struct pt regs *regs) 
{ 
unsigned int depth = bprm->recursion depth; 
int try,retval; 
struct linux binfmt *fmt; 
pid t old pid; 
/* This allows 4 levels of binfmt rewrites before failing hard. */ 
if (depth > 5) 
return -ELOOP; 
retval = security bprm check (bprm); 
if (retval) 
return retvaly 
retval = audit bprm (bprm); 
if (retval) 
return retvaly 
/* Need to fetch pid before load binary changes it */ 
rcu read lock(); 
old pid = task pid nr ns(current, task active pid ns(current->parent)); 
rcu read unlock(); 
retval = -ENOENT; 
/* 最 多 尝试 两 次 ， 第 一 次 遍历 


formats 链 表 中 的 所 有 成 员 ， 


* 若 没 找到 ， 则 尝试 加 载 动 态 模块 ， 再 次 遍历 


A 
for (try=0; try<2; try++) { 
read lock(&binfmt lock); 
list for each entry(fmt, gformats, 1h) { 


int (*fn) (struct linux binprm *, struct pt regs *) = fmt->load binary; 
if (!fn) 

continue; 
if (!try module get (fmt->module)) 

continue; 


read unlock (&binfmt lock); 
bprm->recursion depth = depth + 1; 
retval = fn(bprm, regs); 
bprm->recursion depth = depth; 
if (retval >= 0) { 
if (depth == 0) 
ptrace event (PTRACE EVENT EXEC, 
old pid); 
put binfmt (fmt); 
allow write ”access (bprm->file); 
if (bprm->file) 
fput (hprnm->file)? 
bprm->file = NULL; 
current->did exec = 1; 
proc exec connector (current); 
return retval; 
} 
read lock(&binfmt lock); 


put binfmt (fmt); 

if (retval != -ENOEXEC || bprm->mm == NULL) 
break; 

(!bprm->file) { 

read unlock(&binfmt lock); 

return retval; 


} 


a 


} 
read unlock (&binfmt lock); 
#ifdef CONFIG MODULES 
if (retval != -ENOEXEC || bprm->mm == NULL) { 
break; 
Floe 
#define printable (c) 
站 


(CC (0) Es NE WM (A 
printable (bprm->buf [0]) 
printable (bprm->buf [1]) 
printable (bprm->buf [2]) 
printable (bprm->buf [3]) 
break; /* -ENOEXEC */ 
(try) 

break; /* -ENOEXEC */ 


((c)=='\n') || (0x20<=(c) && 
]) && 
&& 
&& 


) 





村 下 


(c) <=0x7e)) 


request module ("binfmt-%$04x", *(unsigned short *) (gbprm->buf[2])); 


#else 
break; 
#endif 
} 


return retval; 


} 








我 们 可 以 通过 下 面 的 方式 来 查看 自己 机 器 的 编译 选项 ， 














grep BINFMT /boot/config-3.13.0-43-generic 
CONFIG BINFMT ELF=y 

CONFIG COMPAT BINFMT ELF=y 

CONFIG ARCH BINFMT ELF RANDOMIZE PIE=y 
CONFIG BINFMT SCRIPT=y 和 

CONFIG BINFMT MISC=m 


在 内 核 代 码 树 中 代目 录 下 ，Makefile 记 录 了 支持 的 格式 ， 在 全 





从 而 得 知 支 持 的 可 执行 文件 的 类 型 











目录 下 ， 每 一 种 支持 的 格式 xx 都 有 一 个 binfmt xx.c 文 件 。 
































binfmt aout.c 是 对 应 a.out 类 型 的 可 执行 文件 ， 这 种 文件 格式 是 早 





ES 
o 








今天 已 经 退出 了 历史 舞 











日 














binfmt elfc 对 应 的 是 ELF 格 式 的 可 执行 文件 。ELF 最 
的 是 取代 传统 的 a.out 格 式 。1994 年 6 
式 5 




















期 Unix 系 统 使 用 的 可 执行 文件 的 格式 ， 由 AT&T 设 计 ， 





1Unix 系 统 实验 室 (Unix SYSTEM Laboratories USL) 开发 ， 目 
月 ELF 格 式 出 现在 Linux 系 统 上 ， 











目前 ，ELF 格 式 已 经 成 为 Linux 下 最 主要 的 可 执行 文件 格 








binfmt script 对 应 的 是 script 格 式 的 可 执行 文件 ， 这 种 格式 的 可 执行 文件 一 般 以 “#! ”开头 ， 查 找 相应 的 解释 器 来 执行 脚 





本 。 比 如 python 脚 本 、shell 脚 本 和 perl 脚 本 等 。 





早期 的 内 核 之 中 ， 曾 经 为 Java 格 式 提供 了 专门 的 binfmt 结 构 ， 






























































的 binfmt 结 构 。 如 果 专 门 为 Java 提 供 了 ， 其 他 语言 就 会 有 意见 了 ， 
越 来 越 多 ， 大 家 都 可 能 有 自己 
把 这 个 功能 开放 给 了 用 户 层 ， 用 户 可 以 引入 自 





























己 的 这 种 格式 ， 另 外 自己 定义 好 解释 器 就 可 以 了 。 








己 的 可 执行 文件 格式 ， 只 要 你 能 定义 好 magic number， 识 别 出 文 件 是 不 是 











后 来 取消 了 ， 原 因 是 Java 并 不 特殊 ， 不 值得 为 其 提供 专门 
没有 做 到 一 视 同仁 。 但 是 需要 文 持 的 可 执行 文件 的 格式 






























































的 解释 器 ， 内 核 支持 也 不 可 能 无 限 地 增加 binfimt 结 构 ， 这 时 候 ，binfimt_misc 就 出 现 了 。binfimt 




















自 

















binfmt_ misc 这 个 机 制 非常 好 ， 提 供 了 支持 额外 可 执行 格式 的 可 扩展 方法 。 举 例 来 讲 ， 如 果 想 在 Linux 下 执行 Windows 





的 .exe 文件 ，Wine 软 件 可 以 在 Linux 下 执行 Windows 的 exe 文 件 。 


wine application.exe 





























我 们 可 以 将 Windows exe 文 件 注 册 到 binfmt misc， 直 接 使 


./application.exe 


如 下 方法 即 可 执行 exe 文 件 : 





方法 就 是 : 


echo ' :Wine:M::M2::/usr/bin/wine:' > /proc/sys/fs/binfmt misc/register 





如 果 /proc/sys/fs/binfimt_misc 目 录 并 不 存在 ， 则 表明 binfimt_misc 并 没 挂 载 ， 那 就 需要 : 








mount -t binfmt misc binfmt misc /proc/sys/fs/binfmt misc 














或 者 在 /etc/fstab 中 添加 如 下 行 : 





binfmt misc /proc/sys/fs/bpinfmt misc binfmt misc defaults 0 0 





注册 某 种 可 执行 文件 到 binfmt misc 的 格式 时 ，echo 的 内 容 如 下 所 示 : 


:Name:Type:Offset:String:Mask:Interpreter:Flags 














其 中 各 个 字段 的 含义 是 : 

















t 





"Name: 产生 在 /proc/sys/fs/binfmt misc 目 录 下 的 文件 名 ， 代 表 一 种 可 执行 文件 。 











Type: 表示 识别 类 型 ，M 表 示 用 magic numer 来 识别 ，E 表 示 扩 展 。 











Offset: magic number 数 在 文件 中 的 起 始 偏 移 量 。 











“String: 以 magic number 或 以 扩展 名 匹配 的 字符 串 。 


























.Mask: 用 来 屏蔽 String 中 的 一 些 位 的 字符 串 。 


Interpret: 解释 程序 的 完整 路 径 名 。 








:Flags: 可 选 标志 ， 控 制 必须 怎样 调用 解释 程序 。 











HO 


根据 这 个 解释 ， 我 们 echo 语 句 的 含义 是 : Windows 可 执行 文件 的 前 两 个 字 节 是 magic number， 值 为 MZ， 由 解释 和 
序 /usr/bin/wine 执 行 这 个 可 执行 文件 。 



































从 表面 来 看 ， 有 很 多 种 类 型 的 文件 ， 但 是 最 终 都 会 归结 到 ELF 格 式 ， 这 是 因为 那些 脚本 的 解释 器 是 ELF 格 式 。 限 于 篇 
幅 ， 这 里 就 不 介绍 内 核 如 何 加 载 执行 ELF 格 式 的 可 执行 程序 了 。 毛 德 操 前 辈 的 《Linux 内 核 情景 分 析 》 一 书 中 详细 分 析 了 
aout 类 型 的 可 执行 文件 的 加 载 执行 ， 王 柏 生 前 辈 的 《深入 探索 Linux 操 作 系统 》 一 书 中 详细 介绍 了 ELF 类 型 的 可 执行 文件 的 
加 载 执行 ， 感 兴趣 的 朋友 可 以 参看 其 中 的 内 容 。 

























































































4.8.4 ” exec 与 信号 


exec 系 列 函 数 ， 会 将 现 有 进程 的 所 有 文本 段 抛弃 ， 直 接 奔 向 新 生活 。 调 用 exec 之 前 ， 进 程 可 能 执行 
过 signal 或 sigaction， 为 某 些 信号 注册 了 新 的 信号 处 理 函 数 。 一 旦 决裂 ， 这 些 新 的 信号 处 理 函 数 就 无 处 
可 寻 了 。 所 以 内 核 会 为 那些 兽 经 改变 信号 处 理 函 数 的 信号 负责 ， 将 它们 的 处 理 函 数 重 新 设置 为 
SIG_DFL。 






































这 里 有 一 个 特例 ， 就 是 将 处 理 函 数 设 置 为 忽略 〈SIG_IGN) 的 SIGCHLD 信 号。 调用 exec 之 
后 ，SIGCHLD 的 信号 处 理 函 数 是 保持 为 SIG_ IGN 还 是 重 置 成 SIG_DFL，SUSv3 语 下 不 详 ， 这 点 要 取决 于 
操作 系统 。 对 于 Linux 系 统 而 言 ， 采 用 的 是 前 者 : 保持 为 SIG_IGN。 





4.8.5 执行 exec 之 后 进程 继承 的 属性 


执行 exec 的 进程 ， 其 个 性 虽然 叛逆 ， 与 过 去 做 了 决裂 ， 但 是 也 继承 了 过 去 的 一 些 属性 。 
9 了 告警 (如 调用 了 alarm 
建文 件 时 ， 掩 码 umask 和 执行 exec 之 前 一 样 。 表 4-11 给 出 了 执行 exec 之 后 进程 继承 的 属性 。 


程 在 执行 exec 之 前 ， 设 






















































































C 

















函数 ) ， 那 么 在 告 














exec 运 行 之 后 ， 与 进程 相关 的 人 D 都 保持 不 变 。 如 果 进 














警 时 间 到 时 ， 它 仍然 会 产生 
























































个 信号 。 在 执行 exec 后 ， 提 








表 4-11 调用 exec 之 后 进程 保持 的 属性 

属 性 相关 的 函数 属 性 相关 的 函数 
进程 ID getpid 根 目 录 
父 进程 ID getppid 文件 模式 创建 抑 码 umask 
进程 组 ID getpgid 文件 锁 和 记录 锁 flock 和 fentl 
会 话 ID getsid 进程 信号 屏蔽 sigprocmask 
控制 终端 tcgetpgrp 进程 挂 起 的 信号 sigpending 
真实 用 户 ID getsid 已 用 的 时 间 times 
真实 组 ID getgid 资源 限制 getrlimit 、setrlimit 
附加 组 ID getgroups nice 值 nice 
告警 剩余 时 间 alarm semadj 值 semop 
当前 工作 目录 getcwd 









































通过 fork 创 建 的 子 进程 继承 的 属性 和 执行 exec 之 后 进程 保持 的 属性 ， 两 相 比 较 ， 差 异 不 小 。 对 于 fork 而 言 : 
































E 起 信号 依然 保留 。 创 


.告警 剩余 时 间 : 不 仅仅 是 告警 剩余 时 间 ， 还 有 





其 他 定时 器 〈setitimer、timer_ create 等 ) ，fork 创 建 的 子 进程 都 不 继承 。 




















进程 挂 起 信号 : 子 进程 会 将 挂 起 信号 初始 化 为 空 。 











“信号 量 调整 值 semadj: 子 进程 不 继承 父 进程 的 该 值 ， 详 情 请 见 进程 间 通 信 的 相关 音节。 


























:记录 锁 〈fcntt) : 子 进程 不 继承 父 进程 的 记录 锁 。 比 较 有 意思 的 地 方 是 文件 锁 flock 子 进程 是 继承 的 。 




















已 用 的 时 间 times: 子 进程 将 该 值 初始 化 成 0。 








4.9 System 函数 























前 面 提 到 了 fork 冰 数 、exec 系 列 函 数 、wait 系 列 函数 。 库 将 这 些 接口 冯 合 在 一 起 ， 提 供 了 一 个 system 
函数 。 程 序 可 以 通过 调用 system 函 数 ， 来 执行 任意 的 shell 命 令 。 相 信 很 多 程序 员 都 用 过 system 函 数 ， 
为 它 起 到 了 一 个 粘 合剂 的 作用 ， 可 以 让 C 程 序 很 方便 地 调用 其 他 语言 编写 的 程序 。 同 时 ， 相 信 有 很 多 程 
序 员 被 system 函 数 折磨 过 ， 当 出 现 错误 时 ， 如 何 根 据 system 函 数 的 返回 值 ， 定 位 失败 的 原因 古 个 比较 头 
疼 的 问题 。 下 面 我 们 来 细 细 展开 。 
































4.9.1 _ system 函数 接口 


System 函数 的 接口 定义 如 下 : 





#include <stdlib.h> 
int system(const char *command); 





这 里 将 需要 执行 的 命令 作为 command 参 数 ， 传 给 system 函 数 ， 该 函数 就 帮 你 执行 该 命令 。 这 样 看 来 
system 最 大 的 好 处 就 在 于 使 用 方便 。 不 需要 自己 来 调用 fork、exec 和 waitpid， 也 不 需要 自己 处 理 错误 ， 
处 理 信号， 方便 省 心 。 











但 是 system 函 数 的 缺点 也 是 很 明显 的 。 首 先是 效率 ， 使 用 System 运行 命令 时 ， 一 般 要 创建 两 个 进 
程 ， 一 个 是 shell 进 程 ， 另 外 一 个 或 多 个 是 用 于 shell 所 执行 的 命令 。 如 果 对 效率 要 求 比较 高 ， 最 好 是 自己 
直接 调用 fork 和 exec 来 执行 既定 的 程序 





























从 进程 的 角度 来 看 ， 调 用 system 的 函数 ， 首 先 会 创建 一 个 子 进 程 shell， 然 后 shell 会 创建 子 进 程 来 执 
行 command， 如 图 4-15 所 示 。 


system 肯 数 创建 了 shell 





sleep 200 “|< 一 shell 创建 了 子 进 程 来 


图 4-15 system 函 数 的 实现 





调用 system 函 数 后 ， 命 令 是 否 运行 成 功 是 我 们 最 关心 的 事情 。 但 是 system 的 返回 值 比较 复杂 ， 下 面 
通过 一 个 简化 的 不 完备 〈 没 有 处 理 信 号 ) 的 system 实 现 来 讲述 system 函 数 的 返回 值 ， 代 码 如 下 : 











#include<unistd.nhn> 


#include<sys/wait.h> 
#include<sys/types.h> 
int system(char* command) 


int Status ; 
pid t chilg; 
Switch (child = fork()) 
{ 
Case -1: 
return -1; 
case 0: 
execl ("/bin/sh),"sh", 
_exit (127); 
default: 
while (waitpid(child,&status,0) < 0) 
{ 


/* 如 果 系统 调用 被 中 断 ， 则 重启 系统 调用 


*/ 
if(errno != EINTR) 
{ 


status = -1; 
break;} 
} 
else 
eeturn Statuss 





下 面 我 们 来 分 别 讲述 system 函 数 的 返回 值 。 


(1) 当 command 为 NULL 时 ， 返 回 0 或 1 








"-c", command, NULL); 








正常 情况 下 ， 不 会 这 样 用 system。 但 是 command 为 NULL 是 有 用 的 ， 用 户 可 以 通过 调用 
system (NULL) 来 探测 shell 是 否 可 用 。 如 果 shell 存 在 并 且 可 用 ， 则 返回 1， 如 果 系 统 里 面 压根 就 没有 


shell， 这 种 情况 下 ，shel 就 是 不 可 用 的 ， 返 回 0。 














那么 何 种 情况 下 shell 不 可 用 呢 ? 比如 system 函 数 运行 


在 非 Unix 系 统 上 ， 再 比如 程序 调用 system 之 前 ， 执 行 过 了 chroot， 这 些 情况 下 shell 都 可 能 无 法 使 用 。 





command 为 NULL 的 情况 从 简化 版 的 代码 段 中 看 不 出 来 ， 但 是 从 glibc 的 System 函数 源码 中 可 以 看 出 





端倪 : 


glibc-2.17/sysdeps/posix/system.c 


int 
__libc system (const char *line) 
i (line ==" NULL) 
return do system ("exit 0") == 0; 


weak alias ( libc system System) 











(2) 创建 进程 (fork〉 失 败 ， 或 者 获取 子 进程 终止 状态 (waitpid〉 失 败 ， 则 返回 -1 








创建 进程 失败 的 情况 比较 少见 ， 比 较 容易 想到 的 也 就 是 创建 了 太 多 的 进程 ， 超 出 了 系统 的 限制 。 








但 是 等 待 子 进程 终止 状态 失败 ， 是 比较 容易 造 





来 的 。 


前 面 讲 过 ， 子 进程 退出 的 时 候 ， 如 果 SIGCHLD 的 信号 处 理 函 数 是 SIG_IGN 或 用 户 设置 了 
SA_NOCLDWAIT 标 志 位 ， 那 么 子 进程 就 不 进入 僵尸 状态 等 待 父 进程 wait 了 ， 直 接 自 行 了 断 ， 灰 发 烟 
灭 。 但 是 system 函 数 的 内 部 实现 会 调用 waitpid 来 获取 子 进程 的 退出 状态 。 这 就 是 父子 之 前 没有 协调 好 造 
成 的 错误 。 这 种 情况 下 ，system 返 回 -1，errno 为 ECHLD。 

















这 种 错误 的 示范 代码 如 下 : 


signal (SIGCHLD, SIG IGN) ; /* 返 回 


一 1 的 根源 在 于 此 处 


*)/ 
if((status = system(command) )<0) 
{ 
fprintf (stderr,"system return %d (%$s)\n", 
status, strerror (errno) ) ， 
return -2; 


} 


这 种 情况 下 ， 总 是 返回 -1， 错 误 码 是 ECHLD， 如 下 所 示 : 





manu@manu-hacks:~$ ./t sys err "ls" 
SYStem return.c 七 SYS t sys err 七 sys null t System.C 七 System null.c 
system return -1 (No child processes) 








所 以 需要 调用 system 函 数 的 时 候 ， 先 要 确认 SIGCHLD 是 否 被 设 为 SIG_ IGN。 如 果 是 ，system 就 会 返 
回 -1， 而 无 法 判断 command 执 行 成 功 与 否 。 


(3) 如 果子 进程 不 能 执行 shell， 那 么 system 返 回 值 会 与 exit (127) 终止 时 一 样 





示例 代码 如 下 : 


case 0: 
execl ("/bin/sh),"sh","-c",command, NULL); 
_exit (127) ; 


这 里 如 果 执 行 execl 失 败 ， 就 会 执行 到 _exit (127) ， 和 否则 不 会 执行 到 _exit (127) 。 





(4) 如果 所 有 的 系统 调用 都 执行 成 功 ，system 函 数 就 会 返回 执行 command 的 子 shell 的 终止 状态 


因为 shell 的 终止 状态 是 其 执行 最 后 一 条 命令 的 退出 状态 。 这 种 情况 下 就 和 获取 子 进程 的 退出 状态 
一 样 了 。 前 文 详细 提 到 过 ， 可 以 根据 下 面 的 接口 来 判断 : 


WIFEXITED (status) 
WEXITSTATUS (status) 
WIFSIGNALED (status) 
WTIERMSIG (status) 
WCOREDUMP (status) 








综 上 所 述 ， 在 command 不 等 于 NULL 的 情况 下 ， 正 确 判 断 system 返 回 值 的 方法 如 下 : 








if((status = system(command) ) == -1) 


fprintf (stderr,"system() function return -1 ($s)\n" 
strerror (errno) ) ， 





} 
else if (WIFEXITED(status) && WEXITSTATUS (status) == 127) 
{ 


} 
else 
print wait exit (status); 














fprintf (stderr,"cannot invoke shell to exec command ($s) \n",command); 








其 中 print_wait_exit 疯 数 就 是 前 文 介绍 的 通过 宏 来 判断 进程 的 终止 状态 。 


可 以 测试 一 下 上 面 的 方法 。 下 面 的 t_sys 可 执行 程序 是 笔者 用 C 写 的 一 个 工具 ， 该 工具 的 执行 需要 1 








个 参数 ，argv[1] 用 于 接受 要 执行 的 command， 这 里 将 用 上 面 提 到 的 方法 来 判断 command 的 执行 情况 : 





:EE SYS. “LS” 

system return.c t sys t sys err t sys null t system.c t system null.c 
status = 0 

normal termination,exit status = 0 

./t_sys "sleep 100" /* 在 另 一 终端 向 





Sleep 进程 发 送 


SIGINT 信 号 


Ah 

status = 2 

abnormal termination,signal number =2 
./t_sys "nosuchcmd"  /* 执 行 一 个 不 存在 的 命令 


*/ 
sh: 1: nosuchcmd: not found 
cannot invoke shell to exec command (nosuchcmd) 





4.9.2 system 函 数 与 信号 





4.9.1 节 介绍 了 system 函 数 的 用 法 ， 并 且 引 入 了 一 个 system 函 数 的 简单 不 完备 的 实现 。 之 所 以 说 是 不 
完备 的 ， 是 因为 没有 考虑 信号 。 正 确 地 处 理 信 号 ， 将 会 给 system 的 实现 带 来 复杂 度 。 

















首先 要 考虑 SIGCHLD。 如 果 调 用 system 函 数 的 进程 还 存在 其 他 子 进程 ， 并 且 对 SIGCHLD 信 和 号 的 处 
理 函 数 也 执行 了 wait () 。 那 么 这 种 情况 下 ， 由 system 〈) 创建 的 子 进 程 退出 并 产生 SIGCHLD 信 和 号 时 ， 


主 程序 的 信号 处 理 函 数 就 可 能 先 被 执行 ， 导 致 system 函 数 内 部 的 waitpid 无 法 等 待 子 进程 的 退出 ， 这 就 产 
生 了 竞争 。 这 种 竞争 带 来 的 危害 是 双方 面 的 : 



































.程序 会 误 认 为 自己 调用 fork 创 建 的 子 进程 退出 了 。 





`System 国 数 内 部 的 waitpid 返 回 失 败 ， 无 法 获取 内 部 子 进程 的 终止 状态 。 





鉴于 上 述 原因 ，system 运 行 期 间 必须 要 暂时 阻塞 SIGCHLD 信 号 。 








其 他 需要 考虑 的 信号 还 有 由 终端 的 中 断 操 作 (一般 是 ctrlte〉 和 退出 操作 《一 般 是 ctrl+\) 产生 的 
SIGINT 信 号 和 SIGQUIT 信 和 号。 

















调用 system 函 数 会 创建 shell 子 进程 ， 然 后 由 shell 子 进程 再 创建 子 进 程 来 执行 command。 





那么 这 三 个 进程 又 是 如 何 应 对 的 呢 ? SUSv3 标 准 规定 : 





:调用 system 函 数 的 进程 ， 需 要 忽略 SIGINT 和 SIGQUIT 信 号 。 





“system 疯 数 内 部 创建 的 进程 ， 要 恢复 对 SIGINT 和 SIGQUIT 的 默认 处 理 。 





从 还 辑 上 讲 ， 当 命令 传 入 给 system 开 始 执行 时 ， 调 用 system 函 数 的 进程 ， 其 实 已 经 放弃 了 控制 权 。 
所 以 调用 system 函 数 的 进程 不 应 该 响应 SIGINT 信 号 和 SIGQUIT 信 和 号， 而 应 该 由 system 内 部 创建 的 子 进程 
来 负责 响应 。 考 虑 到 system 函 数 执行 的 可 能 是 交互 式 应 用 ， 交 给 system 创 建 的 子 进程 来 响应 SIGINT 和 


SIGQUIT 信 号 更 合情合理 。 
























































用 更 通俗 的 话 来 讲 ， 就 是 调用 system 函 数 ， 在 system 返 回 之 前 会 忽略 SIGINT 和 SIGQUIT， 无 论 是 调 
用 采用 终端 的 操作 〈ctrl+c 或 ctrlf\) ， 还 是 采用 kill 来 发 送 SIGINT 或 SIGQUIT 信 和 号， 调用 system 函 数 的 进 
程 都 会 不 动 如 山 。 但 是 system 内 部 创建 的 执行 command 的 子 进程 ， 对 SIGINT 和 SIGQUIT 的 响应 是 默认 
值 ， 也 就 是 说 会 杀 掉 响应 的 子 进程 而 导致 system 函 数 的 返回 。 




















相对 于 glibc 的 System 函数 实现 ，《LinuxwUnix 系 统 编程 手册 》 提 供 了 一 个 可 读 性 更 好 的 版 本 ， 对 实 





现 感 兴趣 的 朋友 ， 可 以 参阅 该 书 里 面 的 实现 。 











可 以 验证 下 system 对 SIGINT 及 SIGQUIT 信 号 的 行为 模式 是 否 如 前 所 述 。 对 t_sys 对 应 的 进程 执行 kill- 
SIGINT， 进 程 t sys 无 动 于 夷 。 但 是 在 另 一 终端 ， 对 sleep 1000 对 应 的 进程 发 送 SIGINT 信 号 ， 立 刻 就 会 出 
现 如 下 打印 : 

















./t_sys "sleep 1000" 
status = 2 
abnormal termination,signal number =2 


由 1 人 赣 娠 








进程 是 操作 系统 非常 重要 的 概念 。 和 程序 相 比 ， 进 程 是 有 生命 的 ， 是 流动 的 。 本 章 介 绍 了 进程 的 
一 生 ， 从 进程 被 创建 到 调用 exec 奔 向 新 生活 ， 从 进程 退出 到 父 进程 等 待 子 进程 ， 另 外 还 介绍 了 上 述 接口 
的 综合 即 system 函 数 ， 以 及 通过 system 函 数 来 执行 程序 。 
































第 5$ 章 ”进程 控制 : 状态 、 调 度 和 优先 级 








第 4 章 介 绍 了 进程 的 一 生 ， 从 创建 《〈fork 或 vfork) 到 走向 新 的 征程 (exec) ， 从 退出 (exit 或 _exit) 
到 被 父 进程 或 init 进 程 “ 收 性 ”(wait) 。 


本 章 将 介绍 进程 的 其 他 方面 ， 主 要 包括 : 





进程 在 其 或 长 或 短 的 一 生 中 可 能 处 于 的 状态 。 
内 核 如 何 调度 进程 使 用 CPU 资 源 。 
进程 如 何 调整 优先 级 ， 以 求 获 得 更 多 或 更 少 的 CPU 资 源 。 
` 对 于 有 实时 性 要 求 的 进程 如 何 设 置 调度 策略 以 满足 其 要 求 。 


如何 把 进程 绑 定 到 茶 个 或 某 些 CPU 上 执行 。 


5.1 进程 的 状态 





故 际 风 不 终 朝 ， 又 雨 不 终日 。 熟 为 此 者 ? 天 地 。 天 地 尚 不 能 入， 而 况 於 人 乎 ? 


一 一 老子 《道德 经 》 








就 像 人 不 可 能 一 刻 不 停 地 工作 一 样 ， 进 程 也 无 法 始终 占有 CPU 和 运行。 原因 有 三 : 

















进程 可 能 需要 等 待 某 种 外 部 条 件 的 满足 ， 在 条 件 满足 之 前 ， 进 程 是 无 法 继续 执行 的 。 这 种 情况 
下 ， 该 进程 继续 占有 CPU 就 是 对 CPU 资源 的 浪费 。 




















-Linux 是 多 用 户 多 任务 的 操作 系统 ， 可 能 同时 存在 多 个 可 以 运行 的 进程 ， 进 程 个 数 可 能 远 远 多 于 
CPU 的 个 数 。 一 个 进程 始终 占有 CPU 对 其 他 进程 来 说 是 不 公平 的 ， 进 程 调度 器 会 在 合适 的 时 机 ， 选 择 合 
适 的 进程 使 用 CPU 资源 。 





























:Linux 进 程 支持 软 实 时 ， 实 时 进程 的 优先 级 高 于 普通 进程 ， 实 时 进程 之 间 也 有 优先 级 的 差别 。 软 实 
时 进程 进入 可 运行 状态 的 时 候 ， 可 能 会 发 生 抢占 ， 抢 占 当前 运行 的 进程 。 








下 面 ， 首 先 来 讨论 一 下 进程 的 状态 。 


| 





种 状态 (如 


有 
时 
在 





1 进程 状态 概述 














Linux 下 ， 进 程 的 状态 有 以 下 7 种 ， 

















进程 状态 
TASK RUNNING 
TASK INTERRUPTIBLE 
TASK_ UNINTERRUPTIBLE 
TASK STOPPED 
TASK TRACED 
EXIT ZOMBIE 


EXIT DEAD 





首先 是 可 运行 状态 。 






































图 5-1 

















处 于 可 运行 状态 的 进程 是 进程 调度 的 对 象 。 如 
己 的 运行 队列 ， 事 实 上 还 不 止 一 个 ， 根 据 进程 所 
饮 先 级 的 情况 ， 落 在 相应 的 优先 级 的 队列 上 ， 如 果 是 普通 进程 《属于 完 
可 以 根据 一 定 的 算法 从 运行 队列 上 起 
































调度 类 ) ， 则 根据 


红 黑 树 的 相应 位 置 上 。 




















这 样 进程 调度 
































处 于 RUNNING 状 态 的 进程 ， 可 能 了 














FE 在 


见 表 5-1。 


可 运行 状态 。 但 未 必 正 在 使 用 CPU， 也 许 在 等 
可 中 断 的 睡眠 状态 。 
不 可 中 断 的 睡眠 状态 。 

















进程 的 7 种 状态 





5-1 


说 明 
待 调度 
在 等 待 某 个 条 件 的 完成 


与 可 中 断 的 睡眠 状态 类 似 ， 但 是 不 会 被 信号 中 断 


暂停 状态 。 进 程 收 到 某 信号 ， 运 行 被 停止 
被 跟踪 状态 。 和 和 暂停 状态 有 些 类 似 ， 进 程 被 停止 被 另 一 个 进程 跟踪 
僵尸 状态 。 进 程 已 经 退出 ， 但 是 尚未 被 父 进程 或 init 进程 “ 收 户 ” 


真正 死亡 的 状态 。 


该 状态 的 名 称 为 TASK_RUNNING， 严 格 来 说 这 个 名 字 是 不 准确 的 ， 
在 占有 CPU 运 行 ， 将 该 状态 称 为 TASK_RUNABLE 会 更 


有 人 说 Linux 进 程 有 8 种 状态 ， 这 种 说 法 也 是 对 的 。 


进程 停留 在 该 状态 的 时 间 极 得， 很 难 观 察 到 


因为 该 状态 的 确切 含义 是 可 运行 状态 ， 并 非 一 定 是 























佳 确 。 
丸 为 TASK_RUNNIING 可 以 根据 是 否 在 CPU 上 运行 ， 进 一 步 细 分 成 RUNNING 和 READY 两 






































于 CPU 资源 有 限 ， 调 度 器 暂时 并 未 选中 它 运行 。 








只 不 过 








它们 随时 可 以 投入 运行 ， 








图 $-1 所 示 ) 。 处 于 READY 状 态 的 进程 


外， 





果 进 程 并 不 处 于 可 运行 状态 ， 进 程 调度 器 就 不 会 选择 它 投入 和 运行。 在 Linux 中 ， 


户 态 (user-mode) 代码 ， 也 可 能 正 








执行 用 

















时 间 片 耗 尽 
主动 让 出 CPU 
被 更 高 优先 级 的 进程 抢占 


READY 和 RUNNING 状 态 之 间 的 切换 


被 调度 需 选 中 





每 一 个 CPU 都 
属 调度 类 别 的 不 同 ， 可 运行 状态 的 进程 也 会 位 于 不 同 的 队列 上 : 如 果 是 实时 进程 (属于 实 
全 公平 调度 类 ) ， 则 根据 虚拟 运行 时 间 的 大 小 ， 落 
kt 选 合适 的 进程 来 使 用 CPU 资源 。 
































































































































区 





企 执 行内 核 态 〈kernel-mode) 代码 ， 内 核 提 供 了 进一步 的 








分 和 统计 。Linux 提 供 的 time 命 令 可 以 统计 进程 在 用 户 态 和 内 核 态 消耗 的 CPU 时 间 : 














manu@manu-rush:~$ time sleep 2 


real 0m2.009s 
user Om0.001s 
SYS 0m0 .002s 





clocktime) ， 即 进程 从 开始 到 终止 ， 一 3 








time 命 令 统计 了 三 种 时 间 : 实际 时 














运行 所 消耗 的 CPU 时 间 。 








如 何 区 分 用 





间 、 




















户 态 CPU 时 间 和 内 核 态 CPU 时 间 呢 ? 我们 举例 来 说 明 。 如 果 进 程 在 执行 加 减 乘除 或 浮 点 数 计算 或 排序 等 操作 时 ， 


] 户 CPU 时 间 和 系统 CPU 时 间 。 其 中 实际 
人 执行 了 多 久 。user 一 行 统计 的 是 进程 执行 用 

















时 间 最 好 理解 ， 就 是 日 常生 活 中 的 时 间 〈 墙 上 时 间 ，wall 
户 态 代码 消耗 的 CPU 时 间 ; sys 一 行 统计 的 是 进程 在 内 核 态 






























































尽管 这 些 操作 








正在 消耗 CPU 资源 ， 但 是 和 内 核 并 没有 太 多 的 关系 ，CPU 大 部 分 时 间 都 在 执行 用 户 态 的 指令 。 这 种 场景 下 ， 我 们 称 CPU 时 间 消 耗 在 用 户 态 。 如 果 
进程 频繁 地 执行 创建 进程 、 销 毁 进 程 、 分 配 内 存 、 操 作文 件 等 操作 ， 那 么 进程 不 得 不 频繁 地 陷入 内 核 执行 系统 调用 ， 这 些 时 间 都 累加 在 进程 的 
内 核 态 CPU 时 间 。 




































































对 于 这 三 种 时 间 ， 最 容易 产生 的 误解 的 是 real time=user time+sys time。 这 种 想法 是 错误 的 。 在 单 核 系统 上 ，real time 总 是 不 小 于 user time 与 
sys time 的 总 和 。 但 是 在 多 核 系统 上 ，user time 与 sys time 的 总 和 可 以 大 于 real time。 利 用 这 三 个 时 间 ， 我 们 可 以 计算 出 程序 的 CPU 使 用 率 : 





























cpu usage = ((user time) + (sys time))/(real time) 


























在 多 核 处 理 器 情况 下 ，cpu_usage 如 果 大 于 1， 则 表示 该 进程 是 计算 密集 型 《CPU bound) 的 进程 ， 且 cpu_usage 的 值 越 大 ， 表 示 越 充分 地 利用 
了 多 处 理 器 的 并 行 运行 优势 ， 如 果 cpu_usage 的 值 小 于 1， 则 表示 进程 为 /O 密 集 型 (1/O bound) 的 进程 ， 多 核 并 行 的 优势 并 不 明显 。 














































































































time 命 令 的 问题 在 于 要 等 进程 运行 完毕 后 ， 才 能 获取 到 进程 的 统计 信息 ， 正 所 谓 盖 棺 定论 。 有 些 时 候 ， 我 们 需要 了 解 正 在 运行 的 进程 : 它 
运行 了 多 久 ， 内 核 态 CPU 时 间 和 用 户 态 CPU 时 间 分 别 是 多 少 ? procfs 在 /proc/PID/stat 中 提供 了 相关 的 信息 : 




















manu@manu-rush:~$ cat /proc/8283/stat 
8283 (stress) R 8282 8282 7015 34817 8282 4218944 35 0 0 0 15988 35 


02001 
0 3551036 7405568 24 18446744073709551615 4194304 4213100 140736349760736 
140736349760296 139793990053869 000000017000000 6311448 6312216 
17915904 140736349767962 140736349767974 140736349767974 140736349769704 0 





























数组 中 的 每 个 字段 都 有 自己 独特 的 含义 。 如 果 从 0 开始 计数 ， 那 么 字段 13 对 应 的 是 进程 消耗 的 用 户 态 CPU 时 间 ， 字 段 14 记 录 的 是 进程 消耗 的 
内 核 态 CPU 时 间 。 两 者 的 单位 是 时 钟 咬 哄 〈clocktick) 。 
































一 个 时 钟 吐 哄 是 多 久 ? 可 以 通过 如 下 命令 来 获取 : 





grep CONFIG HZ /boot/config- uname -T 
CONFIG HZ 250=y 
CONFIG HZ2=250 








当 配 置 内 核 的 时 候 ， 有 100Hz、250Hz、300Hz 和 1000Hz 这 4 个 选项 。 如 果 配 置 的 频率 为 230Hz， 那 么 1 秒 钟 就 有 250 个 时 钟 咬 哄 ， 即 每 过 4ms， 
增加 一 个 时 钟 咬 哄 〈 内 核 的 jities++) 。 






































系统 提供 了 pidstat 命 令 ， 通 过 该 命令 也 可 以 获取 到 各 个 进程 的 CPU 使 用 情况 ， 如 图 5-2 所 示 。 














manu@Qmanu- rush:~$ pidstat 
Linux 3.13.0-32-generic (manu-rush) 01/30/2016 _x86 64_ 


OO 
DD 
【= 


Command 
init 
kthreadd 
ksoftirqd/0 
rcu_sched 
rcuos/0 
rcuos/1 
migration/0 
watchdog/0 
watchdog/1 
migration/1 
ksoftirqd/1 
khubd 
kworker/V0:1 


1E-18=305 PP SUST %System %CPU 
11:18:39 PH .00 0.03 - 0.03 
11:18:30 PM .00 .00 .00 
ES SO .00 .00 .00 
11:18:30 PM .00 0l | 
11:18:30 PH .00 .00 .00 
11:18:30 PM .00 .00 .00 
11:18:30 PN .00 .00 .00 
11:18:30 PN .00 .00 .00 
11:18:30 PM .00 .00 .00 
11:18:30 PH .00 .02 .02 
11:18:30 PM .00 .00 .00 
11:18:30 PM .00 .00 .00 
11:18:30 PM .00 .08 .08 


DOODODOODOOODOOODOODODOD 
OODOODOPDOoODOoOo0D 
ee 
OOOOOOOOODOOoOOoO0D 
OOPPPROOPOPOPP 














图 5-2 ”使 用 pidstat 观 察 CPU 的 使 用 情况 


























pidstat 可 以 通过 -p 参 数 指定 观察 的 进程 ， 从 而 可 以 获取 到 该 进程 的 CPU 使 用 情况 ， 包 括 用 户 态 CPU 时 间 和 内 核 态 CPU 时 间 ， 如 图 5-3 所 示 。 








manuG@manu- rush: 
Linux 3.13.0-32-generic (manu-rush) 


ks 
ss 
站 
he 
11 


22:01 PN 
22:03 PNM 
22:05 PM 
22:07 PN 
:22:09 PH 





如 何 获得 进程 的 实际 运行 时 间 呢 ? 



























































~$ pidstat -p 3107 2 
901/30/2016 _x86 64 
PID %USr %System %guest %CPU Command 

3107 99.00 0.50 0.00 99.50 stress 
3107 99.00 1.00 0.00 100.00 stress 
3107 99.00 0.50 0.00 99.50 stress 
3107 99.50 1.00 0.00 100.50 stress 

图 5-3 ”使 用 pidstat 观 察 特 定 进程 的 CPU 使 用 情况 

通过 ps 命令 的 etime (elapsed time 的 缩写 ) 可 以 获取 该 值 : 





manu@manu-rush:~$ ps -p 8283 -o etime,cmd,pid 


ELAPSED CMD 













































































































































































































































































PID 
D0239 stregs =& 1 8283 
2. 可 中 断 睡 眠 状态 和 不 可 中 断 睡 眠 状态 
进程 并 不 总 是 处 于 可 运行 的 状态 。 有 些 进 程 需要 和 慢 速 设备 打交道 。 比 如 进程 和 磁盘 进行 交互 ， 相 关 的 系统 调用 消耗 的 时 间 是 非常 长 的 
〈 可 能 在 毫秒 数量 级 甚至 会 更 久 ) ， 进 程 需要 等 待 这 些 操作 完成 才 可 以 执行 接 下 来 的 指令 。 有 些 进 程 需要 等 待 某 种 特定 条 件 〈 比 如 进程 等 待 子 
进程 退出 、 等 待 socket 连 接 、 尝 试 获得 锁 、 等 待 信号 量 等 ) 得 到 满足 后 方 可 以 执行 ， 而 等 待 的 时 间 往 往 是 不 可 预 估 的 。 在 这 种 情况 下 ， 进 程 依然 
占用 CPU 就 不 合适 了 ， 对 CPU 资源 而 言 ， 这 是 一 种 极 大 的 浪费 。 因 此 内 核 会 将 该 进程 的 状态 改变 成 其 他 状态 ， 将 其 从 CPU 的 运行 队列 中 移 除 ， 同 
时 调度 器 选择 其 他 的 进程 来 使 用 CPU 资源 。 
Linux 存 在 两 种 睡眠 的 状态 :可 中 断 的 睡眠 状态 (TASK _INTERRUPTIBLE) 和 不 可 中 断 的 睡眠 状态 CTASK_UNINTERRUPTIBLE) 。 这 两 种 
睡眠 状态 是 很 类 似 的 。 两 者 的 区 别 就 在 于 能 和 否 响应 收 到 的 信号 




















处 于 可 中 断 的 睡眠 状态 的 进程 ， 返 





等待 的 事 





发 生 了 ， 继 续 运 行 的 条 





' 收 到 未 被 屏蔽 的 信号 。 








当 处 于 可 中 断 睡 眠 状态 的 进程 收 到 信 





但 是 对 于 不 可 中 断 的 睡眠 状态 ， 





回 到 可 运行 的 状态 有 以 下 两 种 可 能 


性 : 





件 满足 了 。 








号 时 ， 





会 返回 EINTR 给 








户 空 间 。 程 序 员 需 





要 检测 返 




















回 值 ， 并 做 出 正确 的 处 理 。 








只 有 一 种 可 能 性 能 使 其 返回 到 可 运行 的 状态 ， 即 等 待 的 事件 发 生 了 ， 继 续 运 行 的 条 件 满 足 了 《〈 如 图 $-4 所 
示 ) 。 
等 待 的 事件 发 生 了 等 待 的 事件 发 生 了 
或 收 到 信和 号 












TASK_INTERRUPTIBLE 










TASK_UNINTERRUPTIBLE 


”进程 需要 等 待 某 事件 进程 需要 等 待 某 事件 
发 生 方 能 继续 发 生 方 能 继续 
图 5$-4 可 运行 状态 与 休眠 状态 之 间 的 切换 


TASK_UNINTERRUPTIBLE 状 态 存在 的 意 





意义 在 于 ， 内 核 中 


























入 一 段 用 于 处 型 




















异步 信号 的 流程 ， 原 有 的 流程 就 被 中 断 了 。 攻 
进行 读 操作 ，read 系 统 调用 最 终 执 行 对 应 设备 驱动 的 代码 ， 并 与 对 应 的 物理 设备 交互 ) ， 
来 ， 以 避免 进程 与 设备 的 交互 过 程 被 打 断 ， 致 使 设备 陷入 不 可 控 的 状态 。 

















此 当 进 程 在 对 某 些 硬件 进行 某 些 操 


某 些 处 理 流 程 是 不 应 该 被 打 断 的 ， 如 果 响 应 异步 信号 ， 程 序 的 执行 流程 中 就 会 插 














作 时 《比如 进程 调 












































TASK_UNINTERRUPTIBLE 是 一 种 很 危险 的 状态 ， 因 
个 处 于 不 可 中 断 的 休眠 状态 的 进程 ，SIGKILL 信 和 号 























需要 合 























为 进程 进入 该 状态 
也 不 行 。 























正常 情况 下 ， 








进程 处 于 TASK_UNINTERRUPTIBLE 状 态 的 时 间 会 非常 短 


后 ， 刀 枪 不 入 ， 任 何 信和 号 





都 无 法 打 断 它 。 


暂 ， 











jread 系 统 
43TASK UNINTERRUPTIBLE 








周 用 对 








某 个 文件 














我 们 无 法 通过 信号 


状态 把 进程 保护 起 


杀 和 死 一 


进程 不 应 该 长 时 间 处 于 不 可 中 断 的 睡眠 状态 ， 但 是 这 种 情况 确 

















实 可 能 会 发 生 《〈 内 核 代 码 流程 中 可 能 有 bug， 或 者 用 户 内 核 横 块 中 的 相关 机 制 不 合理 都 会 导致 某 些 进程 长 时 间 处 于 D 状 态 ) 。 举 例 来 讲 ， 当 通 
NFS 访 问 远程 目录 时 ， 异 地 文件 系统 的 异常 可 能 会 使 进程 进入 该 状态 。 如 果 远 端的 文件 系统 始终 异常 ， 使 进程 的 /JO 请 求 得 不 到 满足 ， 该 进程 
一 直 处 于 TASK_UNINTERRUPTIBLE 状 态 ， 无 法 杀 死 ， 除 了 重启 Linux 机 器 之 外 ， 无 药 可 救 。 















































冲 他 


















































内 核 提 供 了 hung task 检 测 机 制 ， 它 会 启动 一 个 名 为 khungtaskd 的 内 核 线程 来 检测 处 于 TASK_UNINTERRUPTIBLE 状 态 的 进程 是 否 已 经 失控 。 
khungtaskd 定 期 被 唤醒 (默认 是 120 秒 〉 ， 它 会 遍历 所 有 处 于 TASK UNINTERRUPTIBLE 状 态 的 进程 进行 检查 ， 如 果 某 进程 超过 120 秒 未 获得 调 
度 ， 那 么 内 核 就 会 打印 出 警告 信息 和 该 进程 的 堆栈 信息 。 




























































































120 秒 这 个 时 间 是 可 以 定制 的 ， 内 核 提 供 了 控制 选项 : 





root@manu-rush:~# sysctl kernel.hung task timeout secs 
kernel.hung task timeout secs = 120 





关于 khungtaskd 的 更 多 细节 ， 可 以 阅读 内 核 Kkernel/hung_task.c 代 码 。 





























无 论 进程 处 于 可 中 断 的 睡眠 状态 ， 还 是 不 可 中 断 的 睡眠 状态 ， 我 们 都 可 能 会 希望 了 解 进程 停 在 什么 位 置 或 在 等 待 什么 资源 。procfs 的 wchan 


提供 了 这 方面 的 信息 ，wchan 是 wait channel 的 含义 。ps 命 令 也 可 以 通过 wchan 获 得 该 信息 : 
















































































manu@manu-rush:~$ echo $$ 

3828 

manu@manu-rush:~$ cat /proc/3828/wchan 

do wait 

manu@manu-rush:~$ ps -p 3828 -o pid,wchan,cmd 
PID WCHAN CMD 
3828 wait -bash 











男 外 一 种 方法 是 查看 进程 的 stack 信 息 ， 方 法 如 下 所 示 : 














manu@manu-rush:~$ sudo cat /proc/3828/stack 
[<£fffffff8106d2c4>] do wait+0xle4/0x260 
[<ffffffff8106e213>] SyS wait4+0xa3/0x100 
[<ffffffff8176847f>] tracesys+0xel/0xe6 
[FEEEEEEFFEEEEEEES)] ONFEEFEEELEEEEELELEE 


























通过 procfs 的 wchan 和 stack， 不 难看 出 ， 当 前 的 bash 正 在 等 待 子 进程 的 退出 。 


























3. 睡 眠 进程 和 等 待 队列 



































进程 无 论 是 处 于 可 中 断 的 睡眠 状态 还 是 不 可 中 断 的 睡眠 状态 ， 有 一 个 数据 结构 是 绕 不 开 的 : 等待 队 列 (wait queue) 。 进 程 但 凡 需 要 休眠 ， 
必然 是 等 待 某 种 资源 或 等 待 某 个 事件 ， 内 核 必 须 想 办 法 将 进程 和 它 等 待 的 资源 《或 事件 ) 关联 起 来 ， 当 等 待 的 资源 可 用 或 等 待 的 事件 已 发 生 











































































































































































































时 ， 可 以 及 时 地 唤醒 相关 的 进程 。 内 核 采用 的 方法 是 等 待 队列 。 
等 待 队列 作为 Linux 内 核 中 的 基础 数据 结构 和 进程 调度 紧密 地 结合 在 一 起 。 当 进程 需要 等 待 特定 事件 时 ， 就 将 其 放置 在 合适 的 等 待 队列 上 ， 
姑 此 等 待 队 列 对 应 的 是 一 组 进入 休眠 状态 的 进程 ， 当 等 待 的 事件 发 生 时 (或 者 说 等 待 的 条 件 满足 时 ) ， 这 组 进程 会 被 唤醒 ， 这 类 事件 通常 包 
































括 : 中 断 《〈 比 如 DISK WO 完成 ) 、 进 程 同步 、 休 眠 时 间 到 时 等 。 





























内 核 使 用 双向 链表 来 实现 等 待 队列 ， 每 个 等 待 队列 都 可 以 用 等 待 队列 头 来 标识 ， 等 待 队列 头 的 定义 如 下 : 








struct _wait queue head { 
spinlock t lock; 
struct list head task list; 

3 

typedef struct _wait queue head wait queue head +t; 
































进程 需要 休眠 的 时 候 ， 需 要 定义 一 个 等 待 队 列 元 素 ， 将 该 元 素 挂 入 合适 的 等 待 队 列 ， 等 待 队 列 元 素 的 定义 如 下 : 





typedef struct wait queue wait queue t; 
struct wait queue { 加 本 
unsigned int flags; 
#define WO FLAG EXCLUSIVE Ox01 
void *private; 
wait queue func t func; 
struct list head task list; 
] 




















等 待 队列 上 的 每 个 等 待 队列 元 素 ， 都 对 应 于 一 个 处 于 睡眠 状态 的 进程 《如 图 5-5 所 示 ) 。 















等 待 队列 元 素 


flags 


等 待 队列 头 


Lock 


task list 


task Tist 


图 5-5 














进程 A 
task struct 


private 


ne 


EE 









进程 B 
task struect 


等 待 队列 元 素 


task list 


睡眠 进程 与 等 待 队列 


内 核 如 何 使 用 等 待 队列 完成 睡眠 ， 以 及 条 件 满 足 之 后 如 何 唤醒 对 应 的 进程 呢 ? 














首先 要 定义 和 初始 化 等 待 队列 头 部 。 等 待 队列 头 部 相当 























内 核 提 供 了 





init waitqueue head 和 DECLARE WAIT_ QUEUE_ HEAD 两 个 宏 ， 




















a 


























其 次 ， 
素 的 初始 化 : 




















于 一 杆 大 旗 ， 没 有 这 杆 大 旗 ， 将 来 的 等 待 队列 元 素 将 成 为 " 孤 魂 野 鬼 ”， 无 处 安放 。 
j 来 初始 化 等 待 队 列 头 部 。 


进程 需要 睡眠 时 ， 需 要 定义 等 待 队 列 元 素 。 内 核 提 供 了 init waitqueue_entry 函 数 和 init_ waitqueue_fonc_entry 函 数 来 完成 等 待 队列 元 





static inline void init waitqueue entry(wait queue t *q, struct task struct *p) 
{ 

G->flags = 0; 

dq->private = p; 

q->func = default _ wake _ function;/* 通 用 的 唤醒 回调 函数 


i 
} 
static inline void init waitqueue func entry(wait queue t *q, 
wait queue func t func) 
» 
G->flags = 0; 
q->private = NULL; 
q->func = func; 


} 
































除 此 以 外 ， 内 核 还 提供 了 宏 DECLARE WAITQUEUE， 也 可 





来 初始 化 等 待 队列 元 素 : 





#define _NAITOUEUE INITIALIZER(name, tsk) { % 
.private = tsk, y 
.func = default wake functionv 长 
.task list = { NULL, NULL } } 

#define DECLARE NAITOUEUE (name, tsk) \ 
wait queue 七 name = WAITQUEUE INITIALIZER (name, tsk) 





从 等 待 队 列 元 素 的 初始 化 函数 或 初始 化 宏 不 难看 出 ， 等 待 队 列 元 素 的 private 成 员 变 量 指向 了 进程 的 进程 描述 符 task_struct， 

















队列 元 素 ， 就 可 以 将 进程 挂 入 对 应 的 等 待 队列 了 。 











等 待 队列 元 素 添加 到 等 待 队列 头 部 指向 的 双向 链表 ， 代 码 如 下 : 
































第 三 步 是 将 等 待 队列 元 素 〈 即 睡眠 进程 ) 放 入 合适 的 等 待 队列 中 。 内 核 同时 提供 了 add_wait queue 和 add_wait queue_exclusive 两 个 函数 来 


此 就 有 了 等 待 





(里 





void add wait queue (wait queue head t *q, wait queue t *wait) 
， 

unsigned long flags; 

wait->flags &= ~WQO FLAG EXCLUSIVE; 

Spin lock irqsave(&q->lock, flags); 

_ add wait queue(q, wait); 

spin unlock irqrestore(&q->lock, flags); 
} 
void add wait queue exclusive (wait queue head t *q, wait queue t *wait) 
{ 

unsigned long flags; 

wait->flags |= WQ FLAG EXCLUSIVE; 

Spin lock irqsave(&q->lock, flags); 

_ add wait queue taill(q, wait); 

spin unlock irqrestore(&q->lock, flags); 


} 





程 等 待 临 界 区 资源 ， 


的 惊 姑 








这 两 个 函数 的 区 别 在 于 : 





个 等 待 队 列 元 素 设置 了 WQ FLAG _EXCLUSIVE 标 志 位 ， 而 另 一 个 则 没有 。 

















个 等 待 队列 元 素 放 到 了 等 待 队列 的 尾部 ， 而 另 一 个 则 放 到 了 等 待 队列 的 头 部 。 


同样 是 添加 到 等 竺 队列， 为 何 同时 提供 了 两 个 函数 ，WQ_FLAG_EXCLUSIVE 标 志 




















不 妨 来 思考 如 下 问题 : 如 果 存 在 多 个 进程 在 等 待 同一 个 条 件 满足 或 同一 个 事件 发 生 《〈 即 等 待 队列 - 



























































足 时 ， 应 该 把 所 有 进程 一 并 唤醒 还 是 只 唤醒 某 
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答案 是 
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WIR 

















唤醒 行为 ， 比 如 wake_up 宏 ， 它 唤醒 第 一 个 带 有 WQ_FLAG _EXCLUSEVE 标 志 位 的 进程 后 就 会 停止 。 























的 流程 。 这 些 宏 包 括 : 























个 或 菜 几 个 进程 ? 





日 十 名 ， 

















体 分 析 。 有 时 候 需 要 唤醒 等 待 队列 上 的 所 有 进程 ， 但 又 有 些 时 候 唤醒 操 
锁 的 持 有 者 释放 锁 时 ， 如 果 内 核 将 所 有 等 待 在 该 锁 上 的 进程 
多 数 的 竞争 者 ， 不 过 是 从 休眠 中 醒 来 ， 然 后 继续 休眠 ， 这 会 浪费 CPU 资源 ， 如 果 等 待 队列 
EXCLUSEVE 标 志 位 来 实现 互 斥 等 待 ，add_wait queue_exclusive 函 数 会 将 带 


















































f 效 应 (thundering herd problem) 。 因 此 内 核 提供 了 WQ _FLAG 
有 该 标志 位 的 等 待 队列 元 素 添加 到 等 待 队列 的 尾部 。 当 内 核 唤 醒 等 待 队 列 上 的 进程 时 ， 等 待 队列 元 素 9 






































到底 有 什么 作用 ? 








上 有 多 个 等 待 队列 元 素 ) ， 那 么 当 条 件 ; 


E 〈EXCLUSIVE) 。 比 如 多 个 进 


























部 



































起 唤醒 ， 导 














% 争 到 锁 资源 ， 而 大 





影响 性 能 。 这 就 是 所 谓 











很 大 ， 还 会 严 




















事实 上 ， 当 内 核 需 要 等 待 某 个 条 件 满足 而 不 得 不 休眠 《或 是 可 中 断 的 睡眠 ， 或 是 不 可 中 断 的 用 





Pp 的 WQ_FLAG_ EXCLUSEVE 标 志 位 会 影响 


























眠 ) 时 ， 内 核 封 装 了 一 些 宏 来 完成 前 面 提 到 





wait event (wq， condition) 

wait event timeout (wq, condition, timeout) 
wait event interruptible(wq, condition) 
wait event 


interruptible timeout (wq, condition, timeout) 


























和 wait_event_ interruptible 的 





第 一 个 参数 指向 的 是 等 待 队列 头 部 ， 表 示 进 程 会 睡眠 在 该 等 队列 上 。 进 程 醒 来 时 ，condition 需 








可 以 被 信号 中 断 。 名 字 中 带 有 _timeout 的 宏 意 味 着 阻塞 等 待 的 超 四 






































| 









































我 们 不 妨 以 wait_event 宏 为 例 ， 欣 赏 一 下 内 核 是 如 何 使 





#define wait event (wq, condition) 


—— 


要 得 到 满足 ， 和 否则 继续 阻 








等 竺 队列， 等待 某 个 条 件 的 满足 的 : 


由 











塞 。 其 中 wait_event 











又 别 在 于 ， 睡 眠 过 程 中 ， 前 者 的 进程 状态 是 不 可 中 断 的 睡眠 状态 ， 不 能 被 信号 中 断 ， 而 后 者 是 可 中 断 的 睡眠 状态 ， 
[时 间 ， 以 jigy 为 单位 ， 当 超时 时 间 到 达 时 ， 无 论 condition 是 否 满足 ， 均 返 





I 








o 








do { \ 
if (condition) 和 
break; \ 
wait event (wq, condition); 
} while (0) 
#define _wait event (wq, condition) \ 
do { \ 
DEFINE WAIT( wait); 
\ 
for (77) { 二 
Prepare to wait(&wq, & wait, TASK UNINTERRUPTIBLE) 人 
if (condition) 2 NAN 
break; \ 
Schedule (); \ 
} \ 


finish wait (&wq, & wait); 
} while (0) 
void 


prepare to wait (wait queue head t *q, wait queue t *wait, int state) 


unsigned long flags; 
wait->flags &= ~WQ FLAG EXCLUSIVE; 
spin lock irqsave(&q->lock, flags); 
if (list empty (&wait->task list)) 
add wait queue (gq, wait); 
set current statel(state); 
spin unlock irqrestore(&q->lock, flags); 





prepare to_wait 函 数 负 责 将 等 待 队列 元 素 添 加 至 
prepare to_wait 的 工作 后 ， 会 检查 条 件 是 否 满足 条 伯 




















上 对 应 的 等 待 队列 ， 同 时 将 进程 的 状态 设 













































































有 睡眠 就 要 有 了 唤醒， 有 wait event 系 列 的 宏 ， 与 之 对 应 的 ， 就 要 有 wake_ up 系列 的 宏 ， 它 们 必须 成 对 出 现 。 这 一 纪 


























成 TASK_UNINTERRUPTIBLE， 完 成 
用 权 ， 等 待 被 唤醒 。 





F ， 如 果 条 件 不 满足 ， 则 调用 schedule () 函数 ， 主 动 让 








wake_up (x) 

wake up nr (X， nr) 

wake up all (x) 

wake up interruptible (x) 

wake up interruptible nr(x, nr) 
wake up interruptible all (x) 








这 些 宏和 前 面 wait_event 系 列 宏 的 配对 使 









































情况 如 图 5-6 所 示 。 























wait event timeout 
a wake up all 


， ， ， ake interruptible 


wake up interruptible nr 
wait ‘event interruptible timeout 、 - 
2 下 Es Wake up interruptible all 


图 5-6 ”wake_event 和 wake_up 配 对 使 用 情况 











































































其 中 该 系列 宏 中 ， 名 字 里 带 _interruptible 的 宏 只 能 唤醒 处 于 TASK_INTERRUPTIBLE 状 态 的 进程 ， 而 名 字 中 不 带 _interruptible 的 宏 ， 既 可 以 唤 
醒 TASK_INTERRUPTIBLE 状 态 的 进程 ， 也 可 以 唤醒 TASK_UNINTERRUPTIBLE 状 态 的 进程 。 





























wake_ up 系列 函数 中 为 什么 有 些 函 数 后 面 有 _nr 和 _all 这 样 的 后 缀 ? 其 实 不 难 猜 到 这 些 后 绥 的 含义 ; 不 带 后 绥 的 表示 最 多 只 能 唤醒 一 个 带 有 































































































WQ_FLAG EXCLUSIVE 标 志 位 的 进程 ， 带 _nr 的 表示 可 以 唤醒 hr 个 带 有 WQ_FLAG _EXCLUSIVE 标 志 位 的 进程 ， 而 带 _all 后 级 的 则 表示 唤醒 等 待 队 
列 上 的 所 有 进程 。 
这 些 wake_up 系 列 的 宏 ， 其 实现 部 分 最 终 都 是 通过 ”wake_up 函 数 的 简单 封装 来 实现 的 ， 如 图 5-7 所 示 。 





wake up interruptible 












wake up interruptible nr 


wake up nr 








wake up interruptible all 








wake up all 


__Wwake up common 


5-7 ”wake_up 系 列 函数 














下 面 来 分 析 下 wake_ up 函数 ， 看 看 内 核 是 如 何 唤 醒 睡 眠 在 等 待 队列 上 的 进程 的 ， 代 码 如 下 : 


























void _ wake up(wait queue _ head t *q, unsigned int mode， 
int nr exclusive, void *key) 
{ 
unsigned long flags; 
Spin lock irqsave(&q->lock, flags); 
_wake up common(q, mode, nr exclusive, 0, key); 
Spin unlock irqrestore(&q->lock, flags); 
} 
static void _wake up common (wait queue head t *q, unsigned int mogde, 
int nr exclusive, int wake flags, void *key) 
{ 
wait queue 七 *curr, *next; 
/* 遍 历 等 待 队列 类 部 对 应 的 双向 链表 


4 
list for each entry safe(curr, next, &q->task list, task list) { 
unsigned flags = curr->flags; 
/* 最 多 唤醒 


nr 设置 了 排他 性 标志 位 的 等 待 进程 ， 以 防止 惊 群 


4 
if (curr->func(curr, mode, wake flags, key) && 
(flags & WO FLAG EXCLUSIVE) && !--nr exclusive) 
break; 























注意 ， 志 有 历 等 待 队列 上 的 所 有 等 待 队列 元 素 时 ， 对 于 每 一 个 需要 唤醒 的 进程 ， 执 行 的 是 等 待 队列 元 素 中 定义 的 ftnc， 最 多 唤醒 mr_exclusive 





个 带 有 WQ FLAG EXCLUSIVE 的 等 待 队列 元 素 。 





























lk 




















在 初始 化 等 待 队列 元 素 的 时 候 ， 需 要 注册 回调 函数 ftnc。 当 内 核 唤 醒 该 进程 时 ， 就 会 执行 等 待 队列 元 素 中 的 回调 函数 。 



































， 是 默认 的 唤醒 回调 函数 。 无 论 是 DECLARE WAITQUEUE 还 是 


ttt 























等 待 队 列 元 素 最 常用 的 回调 函数 是 default_wake_function， 就 像 它 的 名 字 一 档 
init waitqueue_entry， 都 将 等 待 队 列 元 素 的 func 指 向 default_ wake_function。 而 default_ wake function 仅仅 是 大 名 易 易 的 try to_wake_ up 函数 的 简单 封 


装 ， 代 码 如 下 : 











int default wake function(wait queue t *curr, unsigned mode, int wake flags, 
void *key) 
{ 
return try to wake up(curr->private, mode, wake flags); 
} 
























































try_to_wake_up 是 进程 调度 里 非常 重要 的 一 个 函数 ， 它 负责 将 睡眠 的 进程 唤醒 ， 并 将 醒 来 的 进程 放置 到 CPU 的 运行 队列 中 ， 然 后 并 设置 进程 



































的 状态 为 TASK_RUNNING。 在 本 章 的 后 面 会 对 该 函数 进行 详细 的 分 析 。 


4.TASK KILLABLE 状 态 














很 多 文章 在 介绍 TASK _UNINTERRUPTIBLE 状 态 时 ， 都 喜欢 通过 下 面 的 例子 来 创建 一 个 处 于 TASK_UNINTERRUPTIBLE 状 态 的 进程 : 
































#include<stdio.h> 
int main() 
fif(lvfork(})) 


Sleep (100); 
printf ("hello \n"); 
} 





运行 上 述 代 码 编 出 的 程序 : 





root@manu-rush:~# ps ax |grep state d 
5880 pts/2 Dt 0:00 ./state d 
5881 pts/2 + 0:00 ./state d 


















































很 多 文章 认为 ， 调 用 vfork 函 数 创 建 子 进程 时 ， 子 进程 在 调用 exec 函 数 或 退出 之 前 ， 父 进程 始终 处 于 TASK_UNINTERRUPTIBLE 的 状态 。 
实 这 种 说 法 是 错误 的 。 因 为 很 明显 ， 父 进程 可 以 轻易 地 被 信号 杀 死 ， 这 证 明 父 进程 并 不 是 处 于 TASK_UNINTERRUPTIBLE 的 状态 。 













































































root@manu-hacks:~# ps ax |grep state d |grep -v grep 
6787 pts/2 D+ 0:00 ./state d 
6788 pts/2 S+ 0:00 ./state d 
root@manu-hacks:~# kill -9 6787 I 
root@manu-hacks:~# ps ax |grep state d |grep -V grep 
6788 pts/2 S 0:00 ./state_ qi 而 在 程序 运行 的 终端 


manu@manu-hacks:~/code/me/c$ ./state d 
Killed 











入 


























为 什么 进程 的 状态 显示 的 是 D+， 按 照 ps 命令 的 说 法 应 该 是 处 于 不 可 中 断 的 睡眠 状态 ， 可 为 什么 仍然 会 被 信号 杀 死 呢 ? 这 好 像 和 前 面 的 i 
并 不 一 致 。 























事实 上 ，Pps 命 令 输 出 的 D 状 态 不 能 简单 地 理解 成 UNINTERRUPTIBLE 状 态 。 内 核 自 2.6.25 版 本 起 引入 了 一 种 新 的 状态 即 TASK KILLABLE 状 态 











用 





0 。 可 中 断 的 睡眠 状态 太 容易 被 信号 打 断 ， 与 之 对 应 ， 不 可 中 断 的 睡眠 状态 完全 不 可 以 被 信号 打 断 ， 又 容易 失控 ， 两 者 都 失 之 极端 。 而 内 核 新 
引入 的 TASK _KILLABLE 状 态 则 介 于 两 者 之 间 ， 是 一 种 调和 状态 。 该 状态 行为 上 类 似 于 TASK_UNINTERRUPTIBLE 状 态 ， 但 是 进程 收 到 致命 信号 









































〈 即 杀 死 一 个 进程 的 信号 ) 时 ， 进 程 会 被 唤醒 。 





















































FF 面 的 例子 中 vfork 创 建 子 进程 之 后 ，ps 显 示 父 进程 处 于 D 的 状态 ， 却 依然 可 以 被 杀 死 的 原因 就 是 进程 并 不 是 处 于 不 可 中 断 的 睡眠 状态 ， 而 


是 处 于 TASK _KILLABLE 状 态 。 而 这 种 状态 ， 是 可 以 响应 致命 信号 的 。 






















































































有 了 该 状态 ，wait_event 系 列 宏 也 增加 了 killable 的 变 体 ， 即 wait event killable 宏 。 该 宏 会 将 进程 置 为 TASK KILLABLE 状 态 ， 同 时 睡眠 在 等 


待 队 列 上 。 致 命 信号 SIGKILL 可 以 将 其 唤醒 。 


5.TASK STOPPED 状 态 和 TASK TRACED 状 态 























TASK_STOPPED 状 态 是 一 种 比较 特殊 的 状态 。 在 第 4 章 曾经 提 到 过 ，SIGSTOP、SIGTSTP、SIGTTIN 和 SIGTTOU 等 信号 会 将 进程 暂时 停止， 
停止 后 进程 就 会 进入 到 该 状态 。 上 述 4 种 信号 中 的 SIGSTOP 具 有 和 SIGKILL 类 似 的 属性 ， 即 不 能 忽略 ， 不 能 安装 新 的 信号 处 理 函 数 ， 不 能 屏蔽 
等 。 当 处 于 TASK STOPPED 状 态 的 进程 收 到 SIGCONT 信 号 后 ， 可 以 恢复 进程 的 执行 《如 图 $-8 所 示 ) 。 







































































SIGSTOP 
SIGTSTP 


SIGTTIN SIGCONT 
SIGTTOU 
TASK STOPPED TASK RUNNING 
(READY) 


图 5-8 ”可 运行 状态 和 暂停 状态 的 切换 















































TASK_TRACED 是 被 跟踪 的 状态 ， 进 程 会 停 下 来 等 待 跟踪 它 的 进程 对 它 进行 进一步 的 操作 。 如 何 才能 制造 出 处 于 TASK_TRACED 状 态 的 进 
程 呢 ?最 简单 的 例子 是 用 gdb 调 试 程序 ， 当 进程 在 断 点 处 停 下 来 时 ， 此 时 进程 处 于 该 状态 。 




























































































下 面 用 一 个 最 简单 的 hello 程 序 来 验证 gdb 停 下 的 程序 的 确 处 于 TASK_TRACED 的 状态 。 








在 一 个 终端 ，gdb 将 程序 停 下 ， 停 在 断 点 处 : 











Breakpoint 1, main () at hello.c:6 
6 Printf("hel1lo world\n"); 

















在 男 一 个 终端 查看 进程 的 状态 : 








manu@manu-hacks:~$ ps ax |grep hello 
3768 pts/2 8+ 0:00 gdb ./hello 
3770 pts/2 0:00 /home/manu/code/me/c/hello 
manu@manu-hacks:~$ cat /proc/3770/status 
Name: hello 
State: t (tracing stop) 








TASK_ TRACED 和 TASK_STOPPED 状 态 的 类 似 之 处 是 都 处 于 暂停 状态 ， 不 同 之 处 是 TASK_TRACED 不 会 被 SIGCONT 信 和 号 唤醒 。 只 有 调试 进 
程 通过 ptrace 系 统 调 用 ， 下 达 PTRACE_ CONT、PTRACE _DETACH 等 指令 ， 或 者 调试 进程 退出 ， 被 调试 的 进程 才能 恢复 TASK_ RUNNING 的 状 
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7 




































































6.EXIT_ZOMBIE 状 态 和 EXIT DEAD 状态 














EXIT_ZOMBIE 和 EXIT_ DEAD 是 两 种 退出 状态 ， 严 格 说 来 ， 它 们 并 不 是 运行 状态 。 当 进程 处 于 这 两 种 状态 中 的 任何 一 种 时 ， 它 其 实 已 经 死 
去 了 。 内 核 会 将 这 两 种 状态 记录 在 进程 描述 符 的 exit_state 中 ， 不 过 不 想 细 分 的 话 ， 可 以 笼统 地 说 进程 处 于 TASK_ DEAD 状态 。 
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两 种 状态 的 区 别 在 于 ， 如 果 父 进程 没有 将 SIGCHLD 信 号 的 处 理 函 数 重 设 为 SIG_IGN， 或 者 没有 为 SIGCHLD 设 置 SA_NOCLDWAIT 标 志 位 ， 那 
么 子 进程 退出 后 ， 会 进入 僵尸 状态 等 待 父 进 程 或 init 进 程 来 收 尸 ， 和 否则 直接 进入 EXIT DEAD。 如 果 不 停留 在 僵尸 状态 ， 进 程 的 退出 是 非常 快 
因此 很 难 观察 到 一 个 进程 是 否 处 于 EXIT DEAD 状态 。 


































































































5.1.2 ”观察 进程 状态 














5.1.1 节 介绍 了 进程 的 状态 ， 本 节 将 介绍 如 何 观察 进程 当前 所 处 的 状态 。 





在 proc 文 件 系 统 中 ， 在 /proc/PID/status 中 ， 记 录 了 PID 对 应 进程 的 状态 信息 。 其 中 State 项 记录 了 该 进程 的 瞬时 状态 。 因 为 进程 状态 是 不 断 迁 移 
变化 的 ， 所 以 读 出 来 的 结果 是 瞬时 的 值 。 











manu@manu-rush:~$ cat /proc/1/status 
Name: init 
State: S (sleeping) 
































procfs 中 ， 进 程 的 状态 有 几 种 可 能 的 值 呢 ? 一 起 去 查看 内 核 的 源码 。 在 fs/proc/array.c 中 ， 定 义 了 所 有 可 能 的 值 ， 定 义 如 下 : 











static const char * const task state array[] = { 

HR ruining * 0 */ - 
"Ss (sleeping)", 下 

"D (disk sleep)", fe 

"T (stopped)", Pad 4 */ 

"t (tracing stop)", /* 8 */ 

"2 (zombie)™", i 
《dead 

"x (dead)", He a 

"K (wakekill)", J* 2 这 人 

"W (waking)", /* 256 */ 





这 几 种 状态 都 会 从 procfs 中 出 现 吗 ? 并 非 如 此 。 








static inline const char *get task state(struct task struct *tsk) 
{ 
unsigned int state = (tsk->state & TASK REPORT) | tsk->exit state; 
const char * const *p = &task state array[0]; 有 
BUILD BUG ON (1 + ilog2 (TASK STATE MAX) != ARRAY SIZE(task state array)); 
while (state) { 加 加 加 加 
p++; 
state >>= 1; 


return «pe 














只 有 在 TASK_REPORT 宏 出 现 的 状态 加 上 两 个 退出 状态 时 ， 才 能 出 现在 procfs 中 : 























#define TASK REPORT (TASK RUNNING | TASK INTERRUPTIBLE | \ TASK _ UNINTERRUPTIBLE | TASK STOPPED | \ 
_TASK_TRACED) 











从 TASK REPORT 宏 中 可 以 看 出 ， 并 没有 TASK DEAD、TASK WAKEKILL 和 TASK WAKING， 也 就 是 说 在 procfs 中 ， 无 法 观察 到 下 面 这 三 
个 值 ， 它 们 从 不 出 现 : 























"x (dead)", /* 64 */ 
"K (wakekill)", 1* 428 */ 
"W (waking)", /* 256 */ 


























在 vfork 那 个 例子 中 ， 在 procfs 中 查询 进程 状态 时 ， 父 进程 处 于 D (disk sleep) 状态 ， 而 并 没有 出 现 K (wakekill1) ， 原 因 就 在 于 此 。 























江 


bp 么 是 时 候 记 住 ， 会 在 procfs 中 出 现 的 进程 状态 了 : 











"R (running)", 

"Ss (sleeping)", 

"D (disk sleep)", 
"T (stopped)", 

Tt (tracing Stop} "ss 
"2 (zombie)", 

"x (dead)", 














这 就 是 传统 的 进程 7 状态 ， 如 表 5-2 所 示 。 

















表 5-2 ”procfs 中 的 进程 状态 





procfs 中 的 值 进程 状态 
R (running) TASK RUNNING 
S (sleeping) TASK INTERRUPTIBLE 


D (disk sleep) TASK UNINTERRUPTIBLE 


procfs 中 的 值 进程 状态 


T (stopped) TASK _STOPPEDS 


t (tracing stop) TASK TRACED®S 


Z (zombie) EXIT ZOMBIE 


X (dead) EXIT DEAD 

















( 注 : 在 此 处 ，TASK_STOPPED 应 为 ”TASK_STOPPED， 为 了 防止 产生 不 必要 的 困扰 ， 不 做 严格 区 分 。) 


























( 注 : 在 此 处 ，TASK TRACED 应 为 “TASK TRACED， 为 了 防止 产生 不 必要 的 困扰 ， 不 做 严格 区 分 。) 


$.2 ”进程 调度 概述 









































进程 调度 ， 是 任何 一 个 现代 操作 系统 都 要 解决 的 问题 ， 它 是 操作 系统 相当 重要 的 一 个 组 成 部 分 。 首 先 需要 理解 的 一 点 是 ， 进 程 调 
度 器 是 对 处 于 可 运行 (TASK RUNNING) 状态 的 进程 进行 调度 ， 如 果 进 程 并 非 TASK_ RUNNING 的 状态 ， 那 么 该 进程 和 进程 调度 是 没 
有 关系 的 。 





































































































Linux 是 多 任务 的 操作 系统 ， 所 谓 多 任务 是 指 系统 能 够 同时 并 发 地 执行 多 个 进程 ， 哪 怕 是 单 处 理 器 系统 。 在 单 处 理 器 系统 上 支持 多 
任务 ， 会 给 用 户 多 个 进程 同时 跑 的 幻觉 ， 事 实 上 多 个 进程 仅仅 是 轮流 使 用 CPU 资源 。 只 有 在 多 处 理 器 系统 中 ， 多 个 进程 才能 真正 地 做 
到 同时 、 并 行 地 执行 。 



















































































































































































多 任务 系统 可 以 根据 是 否 支 持 抢占 分 成 两 类 : 非 抢占 式 多 任务 和 抢占 式 多 任务 。 在 非 抢占 式 多 任务 的 系统 中 ， 下 一 个 任务 被 调度 
的 前 提 是 当前 进程 主动 让 出 CPU 的 使 用 权 ， 因 此 非 抢占 式 多 任务 又 称 为 合作 型 多 任务 。 而 抢占 式 多 任务 由 操作 系统 来 决定 进程 调 
在 某 些 时 间 点 上 ， 操 作 系统 可 以 将 正在 运行 的 进程 调度 出 去 ， 选 择 其 他 进程 来 执行 。 毫 无 疑问 ，Linux 属 于 抢占 式 多 任务 系统 。 习 
上 ， 大 多 数 的 现代 操作 系统 都 是 抢占 式 的 多 任务 系统 。 
































六 

























































































冯 






























































CPU 是 一 种 关键 的 系统 资源 。 在 普通 PC 上 CPU 的 核 数 不 过 4 核 、8 核 等 ， 在 服务 器 上 可 能 有 16 核 、32 核 甚至 更 多 。 在 系统 负载 始终 
比较 轻 〈 即 可 运行 状态 的 进程 不 多 ) 的 情况 下 ， 进 程 调度 的 重要 性 并 不 大 。 但 是 如 果 系统 的 负载 很 高 ， 有 几 百 上 千 的 进程 处 于 可 运行 
的 状态 ， 那 么 一 套 合理 高 效 的 调度 算法 就 非常 重要 了 。 





























































































































此 外 ， 不 同 的 进程 之 间 ， 其 行为 模式 可 能 存在 着 巨大 的 差异 。 进 程 的 行为 模式 可 以 粗略 地 分 成 两 类 : CPU 消耗 型 《CPUbound) 和 
IO 消耗 型 IO bound) 。 所 谓 CPU 消 耗 型 是 指 进程 因 为 没有 太 多 的 IO 需求 ， 始 终 处 于 可 运行 的 状态 ， 始 终 在 执行 指令 。 而 IO 消耗 型 
是 指 进程 会 有 大 量 IO 请 求 〈 比 如 等 待 键盘 键入 、 读 写 块 设备 上 的 文件 、 等 待 网 络 IO 等 ) ， 它 处 于 可 执行 状态 的 时 间 不 多 ， 而 是 将 更 
多 的 时 间 耗 费 在 等 竺 上。 当然 这 种 划分 方法 并 非 绝 对 的 ， 可 能 有 些 进程 某 段 时 间 表 现 出 CPU 消耗 型 的 特征 ， 另 一 段 时 间 又 表现 出 VO 消 
耗 型 的 特征 。 












































































































































还 有 另外 一 种 进程 分 类 的 方法 ， 如 下 。 























.交互 型 进程 ， 这 种 类 型 的 进程 有 很 多 的 人 机 交互 ， 进 程 会 不 断 地 陷入 休眠 状态 ， 等 待 键盘 和 上 鼠标 的 输入 。 但 是 这 种 进程 对 系统 的 
响应 时 间 要 求 非常 高 ， 用 户 输入 之 后 ， 进 程 必须 被 及 时 唤醒 ， 否 则 用 户 就 会 觉得 系统 反应 迟钝 。 比 较 典 型 的 例子 是 文本 编辑 程序 和 图 
形 处 理 程序 等 。 














































































































































































































批 处 理 型 进程 ， 这 类 进程 和 交互 型 的 进程 相反 ， 它 不 需要 和 用 户 交 互 ， 通 常 在 后 台 执行 。 这 样 的 进程 不 需要 及 时 的 响应 。 比 较 






























































型 的 例子 是 编译 、 大 规模 科学 计算 等 ， 一 般 来 说 ， 这 种 进程 总 是 “被 侮辱 的 和 被 损害 的 ”。 









































:实时 进程 ， 这 类 进程 优先 级 比较 高 ， 不 应 该 被 普通 进程 和 优先 级 比 它 低 的 进程 阻塞 。 一般 需要 比较 短 的 响应 时 间 。 

































































系统 之 中 ， 有 很 多 性 格 各 异 的 进程 ， 这 就 增加 了 设计 调度 器 的 难度 。 有 一 个 很 有 意思 的 比喻 来 描述 调度 器 的 困境 上 : Linux 内 核 
调度 器 就 像 处 境 乾 粹 的 主妇 ， 满 足 孩 子 对 晚餐 的 要 求 便 有 可 能 会 伤害 到 老人 的 食欲 ， 做 出 一 桌 让 男女 老少 都 满意 的 饭菜 实在 是 太 难 
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设计 一 个 优秀 的 进程 调度 器 绝 不 是 一 件 容易 的 事情 ， 它 还 有 很 多 事情 需要 考虑 ， 很 多 目标 需要 达成 : 






































公平 : 每 一 个 进程 都 可 以 获得 调度 的 机 会 ， 不 能 出 现 “ 饿 死 "的 现象 。 





























:良好 的 调度 延迟 : 尽量 确保 进程 在 一 定 的 时 间 范 围 内 ， 总 能 够 获得 调度 的 机 会 。 
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差异 化 : 允许 重要 的 进程 获得 更 多 的 执行 时 间 。 






































:支持 软 实时 进程 : 软 实 时 进程 ， 比 普通 进程 具有 更 高 的 优先 级 。 























竞争 。 这 种 方案 还 有 另外 一 个 好 处 : 
CPU 执行 该 进程 。 这 种 情况 下 上 次 运 


Scheduler〈 脑 残 调度 器 ) 却 表现 甬 


CPU 闲 着 而 另外 一 些 CPU 忙 

















负载 均衡 : 多 个 CPU 之 间 的 负载 要 均衡 ， 不 能 出 现 一 些 CPU 很 忙 ， 而 另 一 些 CPU 很 闲 的 情况 。 
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高 否 吐 量 : 单位 时 间 内 完成 的 进程 个 数 尽 可 能 多 。 
































:简单 高 效 : 调度 算法 要 高 效 。 不 应 
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: 在 系统 并 不 繁忙 的 情况 下 ， 降 低 系统 的 耗 电量 。 








该 在 调度 上 花费 太 长 的 时 间 。 





























存在 着 多 个 处 理 器 ， 那 么 所 有 处 于 可 运行 状态 的 进程 是 应 该 位 于 一 个 队列 上 ， 还 是 每 个 处 理 











的 队列 ? 这 大 概 是 进程 调 


















































多 处 理 器 (SMP) 的 系统 上 ， 
己 


度 首先 要 解决 的 问题 。 














目前 Linux 采 用 的 是 每 个 CPU 都 要 有 自己 的 运行 队列 ， 即 per cpu run queue。 每 个 CPU 去 自己 的 运行 队列 中 选择 进程 ， 这 样 就 降低 了 
缓存 重 利 用 。 某 个 进程 位 于 这 个 CPU 的 运行 队列 上 ， 经 过 多 次 调度 之 后 ， 内 核 趋 于 选择 相同 的 






























































行 的 变量 很 可 能 仍然 在 CPU 的 缓存 中 ， 这 样 就 提升 了 效率 。 














所 有 的 CPU 共用 一 个 运行 队列 这 种 方案 的 弊端 是 显而易见 的 ， 尤 其 是 在 CPU 数目 很 多 的 情况 下 。 我 们 可 以 想象 一 下 如 果 存 在 1024 
个 CPU， 都 要 去 同一 个 运行 队列 取 下 一 




















但 是 凡事 无 绝对 ， 没 有 最 好 的 ， 只 






































个 调度 的 进程 ， 这 种 竞争 无 疑 会 降低 调度 器 的 性 能 。 






































有 最 适合 的 。 对 于 CPU 核 数 比较 少 的 桌面 应 用 来 说 ， 只 有 一 个 运行 队列 的 Brain Fuck 

















出 色 。 D]DB] 
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Linux 选 择 了 每 一 个 CPU 都 有 自己 的 运行 队列 这 种 解决 方案 。 这 种 选择 也 带 来 了 一 种 风险 : CPU 之 间 负 载 不 均衡 ， 可 能 出 现 一 些 
























































不 过 来 的 情况 。 为 了 解决 这 个 问题 ，load_balance 就 内 亮 登场 了 。load_balance 的 任务 就 是 在 一 定 的 时 机 下 ， 
十 将 任务 从 一 个 CPU 的 运行 队列 迁移 到 另 一 个 CPU 的 运行 队列 ， 来 保持 CPU 之 间 的 负载 均衡 。 












































进程 调度 具体 要 做 哪些 事情 呢 ? 概括 地 说 ， 进 程 调度 的 职责 是 挑选 下 一 个 执行 的 进程 ， 如 果 下 一 个 被 调度 到 的 进程 和 调度 前 运行 

















的 进程 不 是 同一 个 ， 则 执行 上 下 文 切 换 ， 将 新 选择 的 进程 投入 运行 。 
























































下 面 根据 调度 的 入 口 点 函数 schedule〈) 来 看 下 进程 调度 做 了 哪些 事情 ， 代 码 如 下 : 





asmlinkage void _ sched schedule (void) 
{ 
struct task struct ESS = current; 
scheqd submit work(tsk); 
__schedule () 7 
中 


static void _sched _schedule (void) 
{ 





struct task struct *prev, *next; 
unsigned long *switch count; 
struct rq *rq; 
int DUO; 
need_ resched: 
preempt disable(); 
cpu = smp processor id(); 
rq = cpu rq(cpu); 
rcu note context switch (cpu); 
prev = rq->curr; 
schedule debug (prev); 
if (sched feat (HRTICK)) 
hrtick clear (rq); 
raw_spin . lock _irq(&rq->lock); 
switch count = &prev->nivcsw; 
if (prev->state && ! (preempt count( 


) & PREEMPT ACTIVE)) { 


if (nke ly (Sioner _ pending state (prev->state, prev))) { 


prev->state = TASK ] RUNNING; 
} else { 


/* 先 前 的 进程 不 再 处 于 可 执行 状态 ， 需 要 将 其 从 运行 队列 中 移 除 出 去 


i 


deactivate task(rgq, prev, DEQUEUE SLEEP); 


REFew=>on rr = 0 


半生 (prev-. >flags & PF WO WORKER) { 
struct task : struct *to _wakeup; 


to wakeup = wq_worker _ sleeping (prev, 人 


if (to wakeup) 


try to wake up local (to wakeup); 


} 
} 


switch count = &prev->nvesw; 


} 
/* 调 度 之 前 的 准备 工作 


* 


pre_schedule (rq，prev);/* 当 前 


CPU 运 行 队列 上 没有 可 运行 的 进程 了 ， 太 闲 了 ， 需 要 负载 均衡 


过/ 
if (unlikely(!rq->nr running)) 
idle balance (cpu, rq); 
/* 将 被 抢占 的 进程 放 入 指定 的 合适 的 位 置 


A 
put _ prev task (rg, prev); 
/* 挑 选 下 一 个 执行 的 进程 


Wy 
next = pick next task (rq); 
/* 清 除 被 抢占 进程 的 需要 调度 的 标志 位 


6 
clear tsk need resched (prev); 
rq->skip clock update = 0; 
/* 如 果 选 中 的 进程 与 原 进程 不 是 同一 个 进程 ， 则 需要 上 下 文 切 换 


~ 
if (likely(prev != next)) { 
rq->nr switchest+t+; 
rq->curr = next; 
++*switch count; 
/* 上 下 文 切换 ， 切 换 之 后 ， 新 选中 的 进程 投入 执行 


大 
- 
context_ switch (rq, prev, next); 
cpu = smp processor id(); 
rq = cpu rq(cpu); 
} else 
raw spin unlock irq(&rq->lock); 
post schedule (rqg); 
preempt _ enable no resched(); 
if (need resched()) 
goto need resched; 














Linux 是 可 抢占 式 内 核 (Preemptive Kernel) ， 从 内 核 2.6 版 本 开始 ，Linux 不 仅 支 持 用 户 态 抢占 ， 也 开始 支持 内 核 态 抢占 。 可 抢占 式 
内 核 的 优势 在 于 可 以 保证 系统 的 响应 时 间 。 当 高 优先 级 的 任务 一 旦 就 绪 ， 总 能 及 时 得 到 CPU 的 控制 权 。 但 是 很 明显 ， 内 核 抢占 不 能 随 
意 发 生 ， 某 些 情 况 下 是 不 允许 发 生 内 核 抢占 的 。 因 此 为 了 更 好 地 支持 内 核 抢占 ， 内 核 为 每 一 个 进程 的 thread_info 引 入 了 preempt_count 计 
数 器 ， 数 值 为 0 时 表示 可 以 抢占 ， 当 该 计数 器 的 值 不 为 0 时 ， 表 示 禁 止 抢占 。 
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并 不 是 所 有 的 时 机 都 允许 发 生 内 核 抢 占 。 以 自 旋 锁 为 例 ， 在 内 核 可 抢占 的 系统 中 ， 自 旋 锁 持 有 期 间 不 允许 发 生 内 核 抢占 ， 否 则 可 
能 会 导致 其 他 CPU 长 期 不 能 获得 锁 而 死 等 。 因 此 在 spin lock 函数 中 〈 通 过 ”raw_spin lock) ， 会 调用 preempt disable 宏 ， 而 该 宏 会 将 进 
星 preempt_count 计 数 器 的 值 加 1， 表 示 不 允许 抢占 。 同 样 的 道理 ， 解 锁 的 时 候 ， 会 将 preempt_count 的 值 减 1〈 通 过 preempt_enable 宏 ) 。 
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static inline void _raw spin lock(raw spinlock t *lock) 


preempt disable(); 

spin acquire(&lock->dep map, 0, 0, _RET IP ); 

LOCK_ CONTENDED (lock, do raw spin trylock, do raw spin lock); 
} 




















preempt count 的 Bit 28 是 一 个 很 重要 的 标志 位 ， 即 PREEMPT_ACTIVE。 该 标志 位 用 来 标记 是 否 正在 进行 内 核 抢占 。 很 明显 ， 设 置 
了 该 标志 位 之 后 ，preempt_count 就 不 再 为 0 了 ， 因 此 也 就 不 允许 再 次 发 生 内 核 抢 占 ， 从 而 使 得 正在 执行 抢占 工作 的 代码 不 会 再 次 被 抢 
占 。 














































































































内 核 的 preempt schedule 函数 是 内 核 抢 占 时 呼叫 调度 器 的 入 口 ， 它 会 调用 _schedule 函 数 发 起 调度 。 在 调用 _schedule 函 数 之 前 ， 会 
设置 进程 的 PREEMPT_ACTIVE 标 志 位 ， 表 示 这 是 从 抢占 过 程 中 进入 _ schedule 函 数 的 。 















































asmlinkage void _ sched notrace preempt schedule (void) 
{ 
struct thread info *ti = eurrent thread info(}?} 
if (likely(ti->preempt count || irqgs_ disabled()) 
return; 
do { 
add preempt count notrace (PREEMPT ACTIVE); 


schedule () 
Sub preempt count notrace (PREEMPT ACTIVE) ， 
barrier(); 十 加 
} while (need resched() ) 

















在 、schedule 函 数 中 ， 内 核 会 检查 进程 的 PREEMPT_ACTIVE 标 志 位 ， 如 果 发 现 了 该 标志 位 置 位 ， 就 不 会 调用 deactivate_task 函 数 将 
其 从 运行 队列 中 移 除 。 










































































PREEMPT_ACTIVE 标 志 位 有 一 个 非常 重要 的 作用 ， 即 防止 不 处 于 TASK_RUNNING 状 态 的 进程 被 抢占 过 程 错误 地 从 运行 队列 中 移 
除 。 这 句 话 非常 地 绕 ， 我 们 结合 _ schedule 函数 的 对 应 代码 来 分 析 该 标志 位 的 作用 。 
























































if (prev->state && !(preempt count() & PREEMPT ACTIVE) ) { 
14f (unlikely (signal _pending . state (prev- bate. prev))) { 
prev->state = TASK RUNNING; 
} else { 
deactivate task(Tq prev, DEQUEUE SLEEP); 
} 
.1} 













































































如 果 进 程 设 置 了 PREEMPT_ ACTIVE 标志 位 ， 上 述 代码 最 外 层 的 条 件 就 不 会 得 到 满足 。 这 么 做 的 用 意 是 : 如 果 进 程 是 被 抢占 而 进入 
了 schedule 函 数 ， 那 么 即使 它 不 处 于 TASK_ RUNNING 状态 不 能 把 它 从 运行 队列 中 移 除 。 


















































为 什么 这 么 做 ? 从 运行 队列 中 移 除 不 处 于 TASK_RUNNING 状 态 的 进程 是 schedule 函 数 份 内 之 事 ， 为 什么 设置 了 PREEMPT _ACTIVE 
标志 位 就 不 能 移 除 呢 ? 












































原因 是 进程 从 TASK_ RUNNING 变 成 其 他 状态 ， 是 一 个 过 程 ， 在 这 个 过 程 中 可 能 发 生 抢占 。 试 想 如 下 场景 : 一 个 进程 刚 把 自己 设 
置 成 TASK _INTERRUPTIBLE， 它 就 被 抢占 了 。 因 为 这 时 候 它 还 没 来 得 及 调用 schedule〈) 主动 交 出 CPU 控制 权 ， 仍 然 在 CPU 上 执行 ， 
这 就 是 非 TASK_ RUNNING 状 态 的 进程 也 会 被 抢占 的 场景 。 对 于 这 种 场景 ， 抢 占 流程 不 应 擅自 将 其 从 运行 队列 中 移 除 ， 因 为 它 的 切换 
过 程 并 未 完成 。 


















































































































































下 面 的 代码 在 wait_event 系 列 宏 中 不 断 出 现 ， 我 们 以 它 为 例 分 析 上 面 提 到 的 问题 : 





























ER 证 
prepare to wait(&wq, & wait, TASK UNINTERRUPTIBLE); 
if (condition) 
break; 
schedule (); 
} 











执行 完 prepare_to_wait 语 句 ， 本 来 是 要 检查 条 件 是 否 满足 的 ， 如 果 这 时 候 被 抢占 ， 假 如 没有 PREEMPT_ACTIVE 标 志 位 ， 那 么 抢占 
过 程 中 调用 的 _schedule 函 数 就 会 将 进程 从 运行 队列 中 移 除 。 如 果 本 来 condition 条 件 满足 了 ， 那 就 错过 了 唤醒 的 机 会 ， 也 许 就 会 永远 休 
眼 了 。 正 确 的 做 法 是 ， 继 续 保留 在 运行 队列 中 ， 后 面 还 有 机 会 被 调度 到 继续 运行 ， 恢 复 运 行 后 继续 判断 条 件 是 否 满足 。 
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上 面 讨论 了 抢占 的 情况 ， 如 果 进 程 不 处 于 TASK RUNNING 的 状态 ， 并 且 PREEMPT _ ACTIVE 并 没有 置 位 ， 那 么 就 有 可 能 会 调用 
deactivate task 函数 将 其 从 运行 队列 中 移 除 。 这 里 说 可 能 是 因为 ， 该 进程 可 能 存在 尚未 处 理 的 信号 ， 如 果 是 这 种 情况 它 并 不 会 被 移 除 出 
运行 队列 ， 相 反 会 被 再 次 设置 成 TASK RUNNING 的 状态 ， 获 得 再 次 被 调度 到 的 机 会 。 
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__schdule 函 数 的 基本 流程 如 图 5-9 所 示 。 流 程 图 中 带 有 背景 色 的 部 分 都 是 调度 框架 里 的 hook 点 。 内 核 的 进程 i 
一 个 新 的 调度 算法 ， 只 需要 实现 一 组 框架 需要 的 钩子 函数 即 可 ， 内 核 将 会 在 合适 的 时 机 调用 这 些 函 数 。 
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度 是 模块 化 的 ， 实 现 
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不 妨 以 deactivate_ task 为 例 ， 来 看 下 调度 框架 与 具体 调度 算法 中 的 函数 之 间 的 关系 。deactivate_ task 函数 的 职责 可 以 顾名思义 ， 即 进 
程 不 再 处 于 TASK_ RUNNING 的 状态 ， 需 要 将 其 从 对 应 的 运行 队列 中 移 除 。 因 此 其 实现 为 ; 




















static void deactivate task (Struct rq *rq, struct task struct *p, int flags) 
{ 

if (task contributes to load(p)) 

rq->nr _uninterruptiblett; 

dequeue task (rq, Bb; flags)s 
中 
static void dequeue task(struct rq *rq, struct task struct *p, int flags) 
{ 

update rq clock(rq); 

sched info dequeued (p); 

p->sched class->dequeue task(rq, p, flags); 























内 核 会 调用 进程 所 属 调度 类 的 dequeue_ task 函数 ， 至 于 调度 类 的 dequeue_ task 函数 具体 做 了 哪些 事情 ， 完 全 由 具体 的 调度 类 来 决 














清除 当前 进程 的 TIFR_NEED_RESCHED 


新 选中 的 进程 和 当前 进程 是 同一 个 





图 5-9 _ schedule 函数 的 基本 流程 














调用 schedule 函 数 时 ， 当 前 进程 可 能 仍然 处 于 可 运行 的 状态 〈 主 动 让 出 CPU 或 被 其 他 进程 抢占 ) ， 因 此 选择 下 一 个 占用 CPU 的 进程 
之 前 ， 需 要 调用 put prev_task 函 数 。 该 函数 的 目的 是 ， 当 前 进程 被 调度 出 去 之 前 ， 留 给 具体 调度 算法 一 个 时 机 来 更 新 内 部 的 状态 〈 如 
图 $-9 所 示 ) 。 和 deactivate task 函 数 一 样 ， 根 据 当前 进程 所 属 的 调度 类 ， 调 用 具体 的 put_prev_task 函 数 。 























static void put prev task (Struct rq *rq, struct task struct *prev) 
{ 


if (prev->on rq || rq->skip clock update < 0) 
update rq clock(rq); 
prev->sched class->put prev task(rgq, prev); 


} 





Linux 内 核实 现 了 如 下 4 种 调度 类 : 
“stop_sched_class: 停止 类 
"rt_sched_class: 实时 类 


-fair_sched_class: 完全 公平 调度 类 





"idle_sched_class: 空闲 类 


这 4 种 调度 类 是 按照 优先 级 顺序 排列 的 ， 停 止 类 〈stop_sched_class) 具有 最 高 的 调度 优先 级 ， 与 之 对 应 的 ， 空 闲 类 
(idle_sched_class) 具有 最 低 的 调度 优先 级 。 进 程 调度 器 挑选 下 一 个 执行 的 进程 时 ， 会 首先 从 停止 类 中 挑选 进程 ， 如 果 停 止 类 中 没有 
挑选 到 可 运行 的 进程 ， 再 从 实时 类 中 挑选 进程 ， 依 此 类 推 。 



















































































pick_next_ task 函数 负责 挑选 下 一 个 运行 的 进程 ， 从 其 实现 逻辑 中 可 以 看 出 ， 系 统 是 按照 优先 级 顺序 从 调度 类 中 挑选 进程 的 〈 如 图 


5-10 所 示 ) 。 





static inline struct task struct * 
pick next task(struct rq *rq) 
{ 
const struct sched class *class; 
struct task struct *p; 
/* 此 处 是 优化 ， 若 所 有 任务 都 局 于 公平 类 ， 则 直接 从 公平 类 中 挑选 下 一 个 类 


if (likely(rgq->nr running == rq->cfs.h nr running)) { 
p= fair sched class.pick next task (rq); 
if (likely(p)) 
return p; 


} 
/* 按 照 调度 类 的 优先 级 ， 从 高 到 低 挑选 下 一 个 进程 ， 直 到 挑选 到 为 止 


for each class(class) { 
p = class->pick next task(rq); 
if (p) 
return p; 
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repsched olass falirosohed olass idle sched class 


图 5-10 ”进程 调度 类 优先 级 次 序 



































优先 级 最 高 的 停止 类 进程 ， 主 要 用 于 多 个 CPU 之 间 的 负载 均衡 和 CPU 的 热 插 拔 ， 它 所 做 的 事情 就 是 停止 正在 运行 的 CPU， 以 进行 
任务 的 迁移 或 插 拔 CPU。 优 先 级 最 低 的 空闲 类 ， 负 责 将 CPU 置 于 停机 状态 ， 直 到 有 中 断 将 其 唤醒 。idle_sched_class 类 的 空闲 任务 只 有 
在 没有 其 他 任务 的 时 候 才 能 被 执行 。 





















































每 一 个 CPU 只 有 一 个 停止 任务 和 一 个 空闲 任务 。 从 上 面 的 职责 描述 也 可 以 看 出 ， 这 两 种 调度 类 属于 诸 神 之 战 ， 和 应 用 层 的 关系 并 
不 大 。 应 用 层 无 法 将 进程 设置 成 停止 类 进程 或 空闲 类 进程 。 


























和 应 用 层 关 系 比 较 密 切 的 两 种 调度 类 是 实时 类 和 完全 公平 调度 类 ， 尤 其 是 完全 公平 调度 类 。 








[1] 参考 资料 见 ， 刘 明 Linux 调 度 器 BFS 简 介 BFS vs CFS https://www.ibm.com/developerworks/cn/linux/1-cn-bfs/。 
[2] BFS 简 介 ，Linux 桌 面 的 极速 未 来 ? 
[3] BFS vs CFS-Scheduler Comparsion: http://cs.unm.edu/~eschulte/classes/cs587/data/bfs-v-cfs_ groves-knockelschulte.pdf。 


5.3 ”普通 进程 的 优先 级 











字 留 在 进程 诬 


9 度 版 











多 





CH 


本 节 将 




























































































祭 全 公 
大 部 分 时 间 里 所 有 可 运行 的 进程 都 属于 完全 公平 
优化 可 见 一 斑 。 
Linux 是 多 任务 系统 ， 在 存在 多 个 可 运行 进程 的 情况 下 ， 系 统 不 能 放任 当前 





























法 都 不 能 回避 的 问题 。 传 统 的 调 
长 ， 当 CPU 运行 队列 上 可 
加 ， 考 虑 到 上 下 文 切换 


度 算法 面临 着 一 种 
运行 进程 的 个 数 比较 多 的 时 候 尤 为 明显 ， 












































] 户 可 






































Ee 











车 











完全 公平 调度 ， 使 用 了 一 种 动态 时 间 片 的 算法 。 它 给 每 个 进 























困境 ， 那 就 是 时 间 片 到 底 多 大 才 合适 ? 如 果 时 间 
感觉 到 明显 的 延迟 。 如 果 时 间 片 太 短 ， 进 程 调 
也 需要 花费 时 间 ， 可 以 想见 ， 大 量 的 时 间 都 浪费 到 了 进程 调度 上 。 


能 会 














旦 分 配 了 使 用 CPU 的 时 间 比 例 。 进 程 调度 设 计 上 ， 有 一 个 很 重要 








延迟 ， 即 保证 每 一 个 可 运行 的 进程 都 至 少 运行 一 次 的 时 间 间 隔 。 比 如 译 
允许 每 个 进程 执行 10 毫 秒 ， 如 果 运 行 队列 上 是 4 个 同等 优先 级 的 进程 ， 





















































可 

















的 进程 比较 少 ， 采 用 








这 种 算法 则 没有 问题 。 





如 果 可 运行 















































不 是 个 好 主意 。 因 为 时 间 片 太 小 ， 进 程 调 度 过 于 频繁 ， 上 下 文 切 换 的 开销 就 不 能 忽 
为 了 应 对 这 种 情况 ， 完 全 公平 调度 提供 



































何 
(通过 sched_yield 调 用) 。 
































度 延 迟 是 20 毫 秒 ， 如 果 运 行 


那么 ， 每 个 进程 可 以 运行 5 毫秒 。 


个 进程 ， 只 要 分 配 到 了 CPU 资源 ， 都 至 少 会 执行 调度 最 小 粒度 的 时 间 ， 除 非 进程 在 执行 过 程 9 





























人 视 了 。 


了 男 一 种 控制 方法 : 调度 最 小 粒度 。 调 度 最 小 粒度 指 的 是 任 一 进程 所 运行 的 时 


1 进程 始终 占 着 CPU。 每 个 进程 运行 多 长 时 间 ， 是 任何 
片 太 大 ， 进 程 执行 前 需要 等 待 的 时 间 就 会 变 


平 调度 类 (Completely Fair Scheduler， 简 称 CFS) 上 。 事 实 上 ， 除 非 将 Linux 用 在 特定 的 领域 ， 否 则 在 
平 调度 类 。 从 内 核 代码 pick_next task 函 数 〈 该 函数 负责 挑选 下 一 个 进程 放 到 CPU 上 执行 ) 中 所 做 的 

















个 调度 算 












































度 的 频率 就 会 增 














要 


的 指标 是 调度 
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队列 上 只 有 2 个 同等 优先 级 的 进程 ， 那 么 可 以 

















可 是 如 果 运 行 队 列 上 有 200 个 同等 优先 级 的 进程 怎么 办 ? 每 个 进程 运行 0.1 毫 秒 ? 这 可 


























sysctl_sched_min granularity， 记 录 在 /proc/sys/kernel/sched_min granularity_ns 


FP， 两 者 的 单位 都 是 纳 秒 。 


FP 执行 了 阻塞 型 的 系统 调 


司 长 度 的 基准 值 。 任 
或 主动 让 出 



































四 


在 Linux 操 作 系 统 中 ， 调 度 延 迟 被 称 为 sysctlL_sched_latency， 记 录 在 /proc/sys/kernel/sched_latency_ ns 中 ， 而 调度 最 小 粒度 被 称 为 








cat /proc/sys/kernel/sched latency ns 
12000000 

cat /proc/sys/kernel/sched min granularity ns 
1500000 
































几 度 延迟 和 调度 最 小 粒度 综合 起 来 看 是 比较 有 意思 的 ， 它 反映 了 在 调 
如 果 运 行 队列 上 可 运行 状态 的 进程 太 多 ， 超 出 了 该 值 ， 调 度 最 小 粒度 和 调 





< 













































































度 延 迟 两 


度 延迟 内 允许 的 最 大 活动 进程 数 
个 目标 则 不 可 能 被 同时 实现 。 






























































。 这 个 值 被 称 为 sched_nr_latency。 




















度 延 迟 
i 保证 调 


























度 最 小 粒度 。 在 这 种 





内 核 并 没有 提供 参数 来 指定 sched_nr_latency， 它 的 值 完全 是 由 调度 延迟 和 调度 最 小 粒度 来 决定 的 。 计 算 公式 如 下 : 
sysct]l sched latency 
Seed mr Jateney — = ss 
全 Sysctl sched min granularity 
因此 调度 延迟 是 一 个 尽力 而 为 的 目标 。 当 可 运行 的 进程 个 数 小 于 sched_mr_ latency 的 时 候 ， 调 度 周 期 总 是 等 于 调 
(sysctl_sched_latency) 。 但 是 如 果 可 运行 的 进程 个 数 超过 了 sched_nr_latency， 系 统 就 会 放弃 调度 延迟 的 承诺 ， 转 T 
情况 下 调度 周期 等 于 最 小 粒度 乘 以 可 运行 进程 的 个 数 ， 代 码 如 下 所 示 : 











static u64 _ sched period(unsigned long nr running) 


u64 period = sysctl sched latency; 


unsigned long nr latency = Sched_nr_ 1atency; /* 进 程 个 数 过 多 ， 无 法 保证 调度 延迟 ， 只 能 保证 调度 最 小 粒度 


本/ 
if (unlikely(nr running > nr latency)) { 
period = sysctl sched min granularity; 
period *= nr_ running; 


return periogd; 


. 





上 述 函 数 





不 难 理解 : 























: 若 运行 队列 中 进程 个 数 小 于 或 等 于 sched_nr_ latency， 那 么 j 





则 度 周 只 











等 于 i 








度 延 迟 。 





j 




















- 若 运 行 队列 中 进程 个 数 大 于 sched_nr_latency， 那 么 调度 周期 则 等 于 可 运 











行进 程 个 数 与 调度 最 小 粒度 的 乘积 。 


有 了 调度 周期 ， 我 们 就 可 以 计算 ， 分 配给 进 

















程 的 运行 时 间 了 : 














分 配给 进程 的 运行 时 间 三 调度 周期 *1/ 运 行 队 列 上 进程 个 数 











到 目前 为 止 ， 所 有 的 讨论 都 是 基于 
应 获得 更 多 的 运行 时 间 。 考 虑 到 这 种 情况 ， 完 4 





d 


完全 公平 调度 通过 引入 调度 权 习 





运行 队列 上 所 有 的 进程 都 有 相同 的 优 4 











间 的 计算 公式 如 下 : 




















pe 





分 配给 进程 的 运行 时 间 三 


Linux 下 每 


© 注意 ”nice 的 英文 含义 是 友好 ，nice 值 越 高 ， 表 示 越 友好 ， 越 i 





内 核定 义 了 一 个 数组 ， 来 表述 每 个 不 同 nice 值 对 应 的 权重 : 

















个 进程 都 有 














来 实现 优 


由 度 周 期 * 进 程 权时 








et 





E 级 ， 进 程 之 间 按 照 权 奸 











E 务 优先 级 比较 高 ， 理 























Et 级 这 个 假设 。 但 























调度 又 引入 了 优 

















后 ， 调 度 周期 内 分 配给 进 





的 比例 ， 分 配 CPU 时 间 。 引 入 权 习 








uy 








/运行 队列 所 有 进 

















个 nice 值 ， 该 值 的 取 值 范围 是 [-20，19]， 











E 级 越 低 。 默 认 的 优先 级 是 0。 





中 nice 值 越 高 ， 表 示 优 4 

















t 级 越 低 。 具 体 说 就 是 同等 情况 下 ， 占 有 的 CPU 资 源 越 少 。 











static const int prio to weight[40] = { 
88761 3 


jw 0 */ 


7 755 56483 
29154 23254 18705 
9548 7620 6100 
3121 2501 1991 
1024 820, 655 
335 272, 215 
110 87, 70 
36 29, 23 


46273, 36291 
14949, 11916 
4904 3906, 
1586 1277 
526, 423 
L192 137 
56, 45 
18, 15 





这 个 数组 基本 是 通过 如 下 公式 来 获得 的 : 




















weight = 1024 / (1.25 ^ nice value) 






































其 中 普通 进 









































程 的 mice 值 等 于 0， 其 权重 为 基 # 


等 于 820， 当 mice 值 为 2 时 ， 权 重 等 于 1024/ (1.25^2)。 





© 注意 ”很 有 意思 的 是 计算 公式 
































运行 队列 里 有 两 个 进 
55% 的 CPU 时 间 。 那 么 两 者 的 权重 

















1/ (1+x) =0.45 

















根据 上 面 的 计算 
Linux 提 供 了 如 下 函数 来 获取 和 修改 进 
































程 ， 一 个 nice 值 为 0， 另 一 


比例 应 该 是 多 少 ? 


的 1.25 是 怎么 来 的 ? 一 般 的 





程 的 nice 值 : 





#include <sys/time.h> 
#include <sys/resource.h> 
int getpriorityl(int which, int who); 


int setpriority(int which, int who, int prio); 





两 个 系统 调 























值 ， 具 体 如 下 : 


-PRIO_PROCESS: 操作 进程 ID 为 who 的 进程 ， 如 果 who 为 0， 那 么 使 用 
:PRIO_PGRP: 操作 进 
PRIO_USER: 操作 所 有 真实 用 


getpriority 函 数 返 回 


那个 ) 。 


















































的 头 两 个 参数 都 是 which 和 who， 这 胁 














哩 组 ID 为 who 的 进 




















个 参数 用 


哩 组 的 所 有 成 员 。 如 果 who 等 了 











户 ID 为 who 的 进程 。 如 果 who 等 于 0， 使 





which 和 who 指 定 进程 的 nice 值 。 如 果 存 在 多 个 进程 符合 指定 的 标准 


当 nice 值 为 1 时 ， 权 重 等 于 1024/1.25， 约 














被 称 为 NICE 0 LOAD。 











的 1024。mice 值 为 0 的 进程 权 导 





念 是 这 样 的 ， 进 程 每 降低 一 个 mice 值 ， 将 多 获得 10% 的 CPU 时 间 。 如 果 
个 nice 值 为 -1。 那 么 按照 约定 ，nice 值 为 0 的 应 该 获得 45% 的 CPU 时 间 ， 而 nice 值 为 -1 的 应 该 获得 




















公式 ， 很 容易 算出 ， 该 值 约 等 于 1.222 左 右 。 内 核 计算 时 ， 选 择 该 值 为 1.25。 有 具体 可 阅读 prio_ to_weight 定 义 

















级 的 进程 。who 参 数 如 何 解释 ， 取 决 了 





于 标识 需要 读 取 和 修改 优 多 




















































































































必 高 的 那个 nice 值 “ 即 mice 值 最 小 的 

































































因为 进程 优先 级 的 范围 为 [-20，19]， 所 以 成 功 的 时 候 ， 返 回 值 也 可 能 是 -1。 因 此 ， 不 能 用 返回 值 是 不 是 -1 来 判断 调用 是 成 功 还 是 失败 。 正 确 




































































































































































的 方法 是 ， 调 用 前 将 errno 设 置 成 0， 然后 调用 getpriority 函 数 。 如 果 返 回 值 是 -1， 并 且 errno 不 是 0， 才 能 确定 调用 失败 。 和 否则 ， 调 用 成 功 。 

errno = 0; 
prio = getpriority (which,who); 
if(prio == -1 && errno != 0) 

/*error handle*/ 
} 

setpriority 函 数 的 返回 值 并 不 存在 getpriority 函 数 的 困境 。 其 成 功 时 返回 0， 失 败 时 返回 -1， 并 置 errno。 常 见 的 errno 见 表 5-3。 
表 5-3 setpriority 函 数 的 出 错 情况 及 说 明 

errno 说 明 
EACCESS 尝试 获取 更 高 的 优先 级 (更 低 的 prio 值 )， 但 是 没有 CAP_SYS_NICE 权限 
EINVAL which 的 值 不 是 PRIO_PROCESS 、PRIO_PGRP 或 PRIO_USER 
ESRCH which 和 who 指定 的 进程 不 存在 
jt 指定 进程 的 有 效用 户 ID 和 调用 进程 的 有 效用 户 ID 不 一 致 ， 且 调用 进程 没有 CAP_SYS_NICE 

权限 



































对 于 其 中 的 EACCESS 错 误 码 ， 这 里 仔细 说 明 一 下 。 在 早期 版 本 的 Linux 中 非特 权 进 程 不 能 提升 优先 级 ， 只 能 降低 优先 级 。 但 在 现在 的 Linux 
中 ， 非 特权 进程 也 能 适当 地 提升 进程 的 优先 级 了 。Linux 提 供 了 RLIMIT_NICE 资 源 限制 。 如 果 一 个 进程 的 RLIMIT_NICE 限 制 为 25， 那 么 其 nice 值 
可 以 提升 到 20-25 三 -5S。 详 情 可 以 查看 getrlimit 函 数 的 手册 。 




























































































调整 进程 的 优先 级 会 有 什么 影响 ? 完全 公平 调度 算法 里 ， 优 先 级 比较 高 nice 值 比较 低 ) 的 进程 会 获得 更 多 的 CPU 时 间 。 






































比如 ， 有 两 个 进程 位 于 CPU 的 运行 队列 上 ， 一 个 nice 值 是 0 〈 权 重 是 1024) ， 另 外 一 个 nice 值 是 s (权重 是 335) ， 按 照 前 面 的 权重 可 以 推 货 
出 ，mice 值 为 0 的 进程 获得 CPU 的 时 间 应 该 是 mice 值 为 5 的 3 倍 。 





bull 









































可 以 通过 一 个 简单 的 测试 来 验证 这 个 结论 : 








#define _GNU SOURCE 
#include <stdio.h> 
#include <stdlib.h> 
#include <math.h> 
#include <unistd.h> 
#include <sched.h> 
#include <string.h> 
#include <errno.h> 
#include <sys/time.h> 
#include <sys/resource.h> 
#include <sched.h> 
int heavy_work() 
{ 
double sum = 0.0; 
unsigned long long i = 0; 
while(1) 
E 
sum = sum + sin(i++); 
} 


return 0 


int main(int argc,char* argv[]) 
{ 
pu set t set 3 
CPU_ ZERO (&set); 
CPU_SET (0, &set); 
int ret = sched setaffinity(0,sizeof (cpu set 七 )，&Set) 7 
if(ret != 0 ) 
fprintf (stderr, "failed to bind the process to cpu 0 (%s)\n", 
strerror (errno)); 
exit (1); 


} 
ret = fork!()} 
if (ret == 0) 
上 
errno = 0; 
ret = setpriority (PRIO PROCESS, 0,5); 
if(ret == -1 && Eerrno l= 0) 
fprintf (stderr,"[%d] failed to change nice value (%s)\n", 
getpid(),strerror (errno)); 
exit (1) 7 
} 
} 
heavy work(); 
return 0; 











jsetpriority 函 数 将 自己 的 mice 值 设置 成 了 $， 而 父 























Ei 














上 面 的 程序 设置 了 进程 的 CPU 亲和力 ， 父 子 进程 都 将 运行 在 CPU 0 上 ， 不 过 ， 子 进程 首先 i 
进程 的 mice 值 是 默认 值 0。 父 子 进 程 都 是 CPU bound 型 的 程序 ， 始 终 处 于 可 运行 状态 。 
































manu@manu-rush:~$ ps -C nice test -o pid,ppid,cmd,etime,nice,pri,psr 
PIN PPID CMD 人 ELAPSED NI PRI PSR 
3885 2695 ./nice test 3502 0 19 0 
3886 3885 ./nice test 35:02 5 14 0 























的 CPU 时 间 应 该 是 子 进程 的 三 倍 左 右 。 通 过 /proc/PID/sched 



































通过 NI 这 一 列 可 以 看 出 ， 父 进程 的 nice 值 是 9， 而 子 进程 的 nice 值 是 5。 父 进程 占用 
































可 以 查看 这 些 调度 的 信息 ， 其 中 se_sum exec_runtime 的 含义 是 累计 运行 的 物理 时 间 。 


站 

















se.sum exec runtime 1584276.837760 子 进程 


se.sum exec runtime 518296.243156 





那么 我 们 比较 一 下 : 
1024-335<3.0567 


1584276.837760=*518296.243156~3.0567 





因 就 是 决定 每 个 进程 运行 时 间 片 的 时 候 ， 是 根据 权重 来 计算 的 。 








从 执行 时 间 上 可 以 看 出 ， 执 行 时 间 几 乎 完美 地 符合 权重 比 。 原 








的 CPU 时 间 的 比例 依然 约 等 于 3: 1。 原 因 是 绝对 的 nice 












































有 意思 的 是 ， 如 果 CPU 运 行 队列 上 的 两 个 进程 的 nice 值 分 别 是 10 和 15， 那 么 两 者 占用 
值 并 不 影响 调度 决策 ， 而 是 运行 队列 上 进程 间 的 优先 级 相对 值 ， 影 响 了 CPU 时 间 的 分 配 。 








$.4 完全 公平 调度 的 实现 


上 一 节 的 全 部 内 容 ， 归 纳 起 来 就 是 下 面 这 个 公式 : 

















分 配给 进程 的 运行 时 间 三 调度 周期 * 进 程 权重 /所 有 进程 权重 之 和 


但 是 上 一 节 并 没有 介绍 完全 公平 调度 的 算法 实现 ， 本 节 将 尝试 介绍 完全 公平 调度 的 内 容 。 完 全 公 
平 调度 的 算法 思想 比较 简单 ， 按 照 CFS 作 者 Ingo Molnar 的 总 结 : CFS 百 分 之 八 十 的 工作 可 以 用 一 句 话 来 
概括 ， 那 就 是 CFS 在 真实 的 硬件 上 模拟 了 完全 理想 的 多 任务 处 理 器 。 








5.4.1 时 间 片 和 虚拟 运行 时 间 








在 Linux 操 作 系统 中 ， 每 个 CPU 都 维护 有 运行 队列 。 在 该 队列 上 可 能 存在 多 个 进程 处 于 可 执行 状态 ， 那 么 哪个 进程 应 该 先 获得 调 
度 呢 ? 
































这 个 问题 和 生活 中 的 某 些 问题 很 像 。 比 如 一 个 游戏 机 ，5 个 小 孩 玩 ， 当 一 个 小 孩 玩 完 自 己 的 时 间 片 后 ， 该 由 哪个 小 孩 接着 来 玩 
呢 ? 肯定 有 一 个 小 孩 跳出 来 说 : 我 玩 的 时 间 最 短 ， 应 该 是 由 我 来 殉 。 这 是 非常 朴素 的 思想 ， 为 每 个 小 朋友 玩 的 时 间 记 账 ， 玩 的 时 间 
最 短 的 小 朋友 将 获得 下 一 个 玩 的 机 会 。 















































在 进程 优先 级 都 相等 的 情况 下 ， 时 间 记 账 是 一 个 非常 好 的 方法 ， 但 是 优先 级 的 存在 ， 给 时 间 记 账 带 来 了 一 定 的 麻烦 。 有 些 进程 
优先 级 比较 高 ， 理 应 获得 更 多 的 CPU 时 间 ， 这 种 情况 下 如 何 进行 时 间 记 账 ? 


















































Linux 引 入 了 虚拟 运行 时 间 来 解决 这 个 记 账 的 问题 。 假 设 CPU 和 运行 队列 上 有 两 个 进程 需要 调度 ，mice 值 分 别 为 0 和 5， 两 者 的 权重 比 
两 个 进程 在 调度 周期 内 
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是 3: 1， 调 度 周期 为 20 写 秒 。 那 么 按照 公式 ， 第 一 个 进程 应 该 运行 15 毫 秒 ， 接 着 第 二 个 进程 运行 5 毫秒 。 尺 


的 实际 运行 时 间 不 同 ， 但 是 我 们 希望 第 一 个 进程 的 15 毫 秒 和 第 二 个 进程 的 $ 毫 秒 ， 时 间 记 账 是 相等 的 。 即 ; 




































































第 一 个 进程 15 毫 秒 的 记 账 值 三 第 二 个 进程 的 5 毫秒 的 记 账 值 

















这 样 两 个 进程 就 能 根据 时 间 记 账 值 的 大 小 交 蔡 执行 了 。 这 种 时 间 加 权 记 账 的 思想 就 是 完全 公平 调度 的 核心 了 。 





























Linux 内 核定 义 了 调度 实体 结构 体 ， 代 码 如 下 : 








struct sched entity { 
struct load weight load; 
struct rb node run node; 


struct list head group node; 
unsigned int on Yq 

u64 exec_start; 

u64 sum exec runtime; 

u64 vruntime; 

u64 prev_sum exec runtime; 


u64 nr migrations; 














述 结构 中 ，sum_exec_runtime 维 护 的 是 真实 时 间 记 账 信息 。 而 vruntime 维 护 的 则 是 加 权 过 的 时 间 记 账 ， 即 虚拟 运行 时 间 。 




















如 何 根据 真实 的 时 间 计 算出 虚拟 的 运行 时 间 ， 作 为 加 权 过 的 时 间 记 账 ? 公式 如 下 。 

















NICE 0 LOAD 
进程 权重 


在 该 公式 中 ，NICE 0 LOAD 的 值 是 nice 值 为 0 的 进程 的 权重 ， 即 1024。 前 面 的 例子 中 ，nice 值 为 0 的 进程 运行 了 15 毫 秒 ， 因 为 其 权 
重 为 1024， 故 其 虚拟 运行 时 间 也 为 15 毫 秒 ，nice 值 为 5 的 进程 运行 时 间 为 5 毫秒 ， 因 为 其 权重 为 335， 所 以 记 账 时 其 虚拟 运行 时 间 为 : 


加 权 和 运行 时 间 三 真实 运行 时 间 X 

























































































1024 


335 





SX 











运行 时 间 ， 其 实现 代码 如 下 : 











将 
[ey 


内 核 的 sched_slice 函 数 负 责 计算 进程 在 本 轮 调度 周期 应 分 得 的 真 3 








static u64 sched slice (struct cfs rq *cfs rq, struct sched entity *se) 


/* 本 轮 调度 周期 的 时 间 长 度 


*y 
u64 slice = sched periodl(cfs rq->nr running + !se->on rq); 
/*Linux 支 持 组 调度 ， 所 以 此 处 有 一 个 循环 ， 


* 如 果 不 考 虑 组 调度 ， 将 调度 实体 简化 成 进程 ， 会 更 好 理解 


大 
/ 
for each sched entity(se) { 
struct load weight *1load; 
struct load weight lw; 
cfs rq = cfs rq of(se); 
load = &cfs rq->load; 
if (unlikely(!se->on rq)) { 
lw = cfs_ rq->load; 
update load add(&lw, se->load.weight); 
load = &lw; 


} 
/* 根 据 调度 实体 所 占 的 权重 ， 分 配 时 间 片 的 大 小 


wy 
slice = calc delta mine(slice, se->load.weight, lo0ad); 
} 


return slice; 








在 这 个 函数 中 ，calc_delta_mine 函 数 就 是 用 来 计算 分 配 这 个 调度 实体 的 时 间 片 长 度 : 





分 配给 进程 的 运行 时 间 


三 调度 周期 


* 进程 权重 


人， 所 有 进程 权重 之 和 


slice = calc delta mine(slice, se->load.weight, lo0ad); 














在 下 一 节 中 可 以 看 到 ， 内 核 会 周期 性 地 检查 进程 是 不 是 已 经 耗 完了 自己 的 时 间 片 ， 检 查 的 方法 就 是 判断 进程 本 轮 运行 时 间 是 
已 经 超过 了 sched_slice 计 算出 来 的 时 间 片 。 如 果 超 过 ， 则 表示 运行 时 间 足 够 入 了 ， 应 该 发 生 一 次 抢占 。 





上 由 






































更 新 进程 虚拟 运行 时 间 的 逻辑 位 于 内 核 的 _update_curr 函 数 ， 该 函数 里 更 
了 CEFS 运 行 队列 的 最 小 虚拟 运行 时 间 。 





所 了 当前 进程 的 真实 运行 时 间 和 虚拟 运行 时 间 ， 同 时 也 








心 

















static inline void 
_ Update currl(struct efs rg *ofs rq Btruct sched entity *ourry 
unsigned long delta exec) 


unsigned long delta exec weighted; 
schedstat set (curr->statistics.exec max, 

“max((u64)delta exec, curr->statistics.exec max)); 
/* 更 新 进程 的 真实 运行 时 间 


A 
Curr->sum exec runtime += delta exec; 
schedstat add(cfs _rq, exec clock, delta .exec)? 
/*calc_delta fair 用 来 计算 加 权 后 的 运行 时 间 

区 
delta exec weighted = calc _ delta fair(delta exec curr); 
/* 更 新 进程 的 虚拟 运行 时 间 

%y 


curr->vruntime += delta exec weighted; 
/* 更 新 运行 队列 的 最 小 虚拟 运行 时 间 


*/update min vruntime (cfs rq); 

#if defined CONFIG SMP && defined CONFIG FAIR GROUP_SCHED 
cfs_rq->load unacc exec time += delta exec; 

#endif 

} 





运行 队列 的 最 小 虚拟 运行 时 间 是 什么 ? 为 什么 需要 它 ? 


























运行 队列 上 存在 多 个 进程 ， 随 着 时 间 的 流逝 ， 每 个 进程 的 虚拟 时 间 各 不 相同 ， 内 核 会 将 所 有 进程 中 虚拟 运行 时 间 的 最 小 值 记录 
到 运行 队列 的 最 小 虚拟 运行 时 间 (vruntime〉 中 。 当 然 运行 队列 的 最 小 虚拟 运行 时 间 是 奔流 向 前 的 ， 只 会 单调 增 大 ， 绝 不 会 减 小 。 
















































































IT 

















为 什么 要 维护 这 个 值 ? CFS 算 法 可 确保 队列 上 的 所 有 进程 步调 一 致 地 轮流 运行 ， 虚 拟 运 行 时 间 不 断 增 大 ， 大 部 分 进程 的 虚拟 运行 
时 间 相 差 也 不 会 太 远 。 但 是 记录 下 队列 虚拟 运行 时 间 的 最 小 值 仍然 是 有 意义 的 。 比 如 新 加 入 一 个 进程 ， 应 该 给 它 的 虚拟 运行 时 间 赋 
初始 值 ， 初 始 值 应 是 多 少 ? 再 比如 进程 陷入 了 漫长 的 休 卢 ， 醒 来 时 已 经 沧海 桑田 ， 相 对 其 他 进程 ， 它 的 虚拟 运行 时 间 已 经 大 幅 落 
后 。 内 核 应 该 将 该 进程 的 虚拟 运行 时 间 调 整 成 何 值 ? 又 比如 内 核 不 得 不 将 某 个 进程 从 一 个 CPU 的 运行 队列 拉 到 另 一 个 CPU 的 运行 队列 
中 ， 该 进程 的 虚拟 运行 时 间 该 如 何 调整 ? 此 时 ， 维 护 运行 队列 的 最 小 虚拟 运行 时 间 的 意义 就 彰显 出 来 了 。 运 行 队列 的 最 小 虚拟 运行 
时 间 给 了 我 们 一 个 基准 ， 根 据 这 个 基准 值 可 以 知道 ， 该 CPU 运行 队列 上 的 大 部 分 进程 的 虚拟 运行 时 间 就 在 该 值 附近 ， 且 大 于 该 值 。 
在 后 面 分 析 新 创建 的 进程 和 唤醒 休眠 进程 时 ， 会 分 析 内 核 如 何 调 整 这 些 进程 的 虚拟 运行 时 间 。 







































































































































































































































































进程 有 了 虚拟 运行 时 间 ， 完 全 公平 调度 器 挑选 下 一 个 运行 程序 时 就 变 得 非常 简单 了 ， 只 需要 挑选 具有 最 小 虚拟 运行 时 间 
Cvruntime) 的 进程 投入 运行 即 可 。 这 就 是 完全 公平 调度 算法 的 核心 所 在 。 



















































































内 核 为 了 加 速 挑选 具有 最 小 虚拟 运行 时 间 的 进程 ， 使 用 了 红 黑 树 数据 结构 。 运 行 队 列 上 的 所 有 调度 实体 都 是 红 黑 树 的 节点 。 红 
黑 树 是 平衡 二 又 树 的 一 种 ， 调 度 实体 的 虚拟 运行 时 间 是 红 黑 树 的 键 值 。 虚 拟 运 行 时 间 最 小 的 调度 实体 ， 位 于 红 黑 树 的 最 左 端 。 因 此 
挑选 下 一 个 运行 程序 ， 就 简化 成 了 从 红 黑 树 上 取出 最 左 端 的 节点 (如 图 5-11 所 示 )。 
















































































图 5-11 调度 器 根据 虚拟 运行 时 间 (vruntime〉 将 进程 在 红 黑 树 中 排序 


















































维护 进程 的 虚拟 运行 时 间 就 成 了 调度 算法 的 关键 。 问 题 是 何 时 会 更 新 进程 的 虚拟 运行 时 间 呢 ? 可 以 查看 内 核 代 码 中 所 有 调用 
update_curr 的 函数 。 内 核 会 周期 性 地 更 新 进程 的 虚拟 运行 时 间 ， 也 会 在 某 些 合适 的 时 间 点 调用 update_curr 更 新 。 我 们 暂时 强 忍 好 奇 ， 
继续 探索 。 在 探索 的 过 程 中 ， 会 多 次 遇 到 调用 update_curr 的 函数 。 



















































































5.4.2 ”周期 性 调度 任务 
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周期 性 调度 任务 是 调度 框架 中 很 重要 的 一 个 部 分 。 因 为 Linux 是 抢占 式 多 任务 ， 系 统 需要 周期 性 地 检查 ， 当 前 运行 的 进程 是 不 是 已 经 
耗 尽 了 它 的 时 间 片 ， 是 不 是 应 该 发 起 一 次 抢占 了 。 这 就 是 周期 性 调度 任务 的 职责 。 
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时 钟 发 生 中 断 时 ， 首 先 调用 的 是 tick handle_peroid 函 数 。 该 函数 会 调用 scheduler tick 函 数 ， 而 scheduler tick 函 数 是 进程 调度 框架 中 
的 重要 函数 ， 负 责 处 理 进 程 调度 相关 的 周期 性 任务 ， 如 图 $-12 所 示 。 


task tick 
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5-12 scheduler tick 函 数 的 调用 栈 关系 

















在 scheduler tick 函 数 中 一 个 非常 重要 的 调 ) 














外 








curr->Behed class->task ticklrg; curr, OO» 











在 Linux 的 实现 中 调度 器 采用 了 模块 化 的 实现 ， 任 何 一 个 调度 类 ， 都 要 实现 task tick 这 个 函数 。 那 这 个 task tick 函 数 要 完成 哪些 使 命 
呢 ? 主要 的 工作 是 更 新 当前 运行 进程 调度 相关 的 统计 信息 ， 以 及 判断 是 否 需要 发 生 调度 。 

















对 于 完全 公平 的 调度 而 言 ，task tick 函 数 为 ; 





“task tick = task tick fair, 
































在 task_tick_fair 函 数 中 ， 内 核 更 新 了 正在 运行 的 进程 的 时 间 统 计 ， 包 括 真实 运行 时 间 和 虚拟 运行 时 间 ， 代 码 如 下 : 








static void task tick fair(struct rq *rq, struct task struct *curr, int queued) 
{ 


struct cfs rq *cfs rq; 


struct sched entity *se = &CUurr->sey 
/* 为 了 支持 组 调度 ， 引 入 了 调度 实体 的 概念 


wy 
for each sched entityl(se) { 
cfs "2 = Cis Tq OF tae)y 
entity tick(cfs rq, se, queued); 
} 
} 
static void 


entity tick(struct cfs rq *cfs rq, struct sched entity *curr, int queued) 


/* 更 新 正在 运行 进程 的 统计 信息 


wy 
update curr(cfs rq); 
update entity shares tick(cfs rq); 


/* 如 果 可 运行 状态 的 进程 个 数 大 于 


1， 检 查 是 否 可 以 抢占 当前 进程 


wy 
if (cfs rq->nr running > 1) 
check preempt tick(cfs rq, curr)} 
} 





在 我 们 探索 的 第 一 ， 
数 更 新 调度 的 统计 信息 。 它 随 着 时 钟 


间 等 。 


内 核 需要 知道 在 什么 时 候 刘 
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给 用 户 程 











行 一 次 调度 
睡眠 状态 醒 来 时 ，try to_wake_ up 函数 也 会 判断 


I 


么 用 


jschedule 函 数 ， 而 不 能 仅仅 依靠 用 
这 ， 那 么 用 户 程序 可 能 会 无 止 尽 地 执行 下 去 ， 


站 就 遇 到 了 更 新 updat_curr 的 地 方 。 时 钟 中 断 触 发 了 周期 怕 
FP 断 处 理 函 数 周 期 性 地 执行 ， 更 新 进程 的 虚 把 









































生 的 调度 任务 ， 其 中 一 项 重要 的 任务 就 是 通过 updat_curr 函 
才 间 和 运行 队列 的 最 小 虚拟 运行 时 











瑟 


运行 时 间 、 真 实 运行 时 


Schedule 函数 。 如 果 将 schedule 函 数 的 发 起 完全 委托 

























































































。 很 明显 ， 伴 随 着 时 钟 中 断 发 生 的 周期 性 调 
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程 使 用 


static void 
check preempt tick(struct cfs rq *cfs rq, 


4 


片 ， 就 会 执行 resched_ task 函数 ， 在 该 函数 
数 。 如 果 进 程 的 本 轮 运 行 时 间 小 于 调度 最 小 粒度 


unsigned long ideal runtime, delta exec; 


struct sched entity *ses 
s64 delta; 
/*ideal runtime 记 录 进 程 应 该 运行 的 时 间 


ideal runtime = sched slicel(cfs _rq, curr); 


/* delta _exec 记 录 进 程 真实 运行 的 时 间 


日 不老 
是 否 需 要 设 


运行 队列 上 处 于 可 运行 状态 的 进程 不 止 一 个 时 ， 内 核 会 调用 
完 自 己 的 时 间 片 后 ， 可 以 及 时 地 让 出 CPU， 代 码 如 下 : 



































struct sched entity *eurr) 


Bh 
delta exec = curr->sum exec runtime - curr->prev sum exec runtime; 


/* 如 果实 际 运行 时 间 超 过 了 应 该 运行 的 时 间 ， 则 需要 调度 出 去 ， 被 抢占 


if (delta exec > jideal runtime) { 


/*resched task 会 负责 设置 


need_rescheqd 标 志 位 


wy 
resched task(rq of(cfs rq)->curr); 
clear buddies (cfs rq Curr): 
return; 

} 


/* 如 果 当 前 进程 运行 时 间 低 于 调度 的 最 小 粒度 ， 则 不 允许 发 生 抢占 


if (delta exec < SYSsct1_sched min granularity) 


return; 














在 check_preempt tick 中 可 以 看 出 ， 进 程 有 自 


己 的 完美 运行 时 间 ， 
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户 程 序 显 式 地 调用 
而 导致 其 他 进程 饿 死 。 内 核 提 作 
度 任 务 是 一 个 非常 好 的 时 机 来 判断 当前 进程 是 否 应 该 
置 need_resched 标 志 位 来 抢占 当前 的 进程 ) 。 


check preempt tick 函 数 来 检查 是 否 应 该 发 生 


数 中 会 通过 set tsk need_resched 函 数 来 设置 need_resched 标 志 位 ， 


， 那 么 不 允许 发 生 抢 占 。 





三 三 三: 


t 了 一 个 need_resched 标 志 位 来 表明 是 否 需要 重新 执 
玄 被 抢占 〈 另 一 个 时 机 是 进程 从 
























































生 抢占 。 该 函数 确保 了 当前 进 




















即 本 轮 调度 周期 应 得 的 时 间 片 。 如 果 本 轮 执行 时 间 已 经 超出 了 时 间 
告诉 内 核 请 尽快 调用 schedule 函 












































时 ，check preempt tick 


EE 








竺 中 断 返 



































Tesched task 函数 仅仅 是 设置 
函数 是 scheduler tick 函 数 的 一 部 分 ， 而 scheduler : 



































标志 位 ， 并 没有 真正 地 执行 进程 切换 。 进 程 调度 发 生 的 时 机 之 一 是 发 生 在 


tick 函 数 是 中 断 处 理 程序 的 一 部 分 。 执 行 完 9 








位 ， 如 果 置 位 ， 那 就 自然 会 调用 schedule 函 数 来 执行 切换 。 



































FP 断 处 理 ， 会 检查 need_resched 标 志 位 是 否 置 














5.4.3 ”新 进程 的 加 入 


刚 创 建 的 普通 进程 ， 它 的 虚拟 运行 时 间 是 0 吗 ? 














这 个 问题 的 答案 很 明显 ， 如 果 新 创建 进程 的 vruntime 是 90， 那么 它 的 值 会 比 已 经 长 时 间 运 行 的 进程 的 虚拟 运行 时 间 小 很 多 。 它 会 在 
相当 长 的 时 间 内 保持 着 调度 的 优势 ， 一 直 运 行 。 这 显然 是 不 合理 的 。 
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为 了 系统 地 回答 上 面 的 问题 ， 我 们 跟踪 下 新 进程 出 生 之 后 ， 发 生 了 哪些 事情 ， 图 5-13 是 在 创建 新 进程 的 过 程 中 与 进程 调度 有 关系 
的 流程 。 




















首先 分 析 一 下 sched_fork 的 内 核 代码 : 




















void sched fork(struct task struct *p) 


unsigned long flags; 
int cpu = get cpul(}: 
/* 初 始 化 调度 相关 的 值 ， 如 调度 实体 、 运 行 时 间 、 虚 拟 运 行 时 间 等 


sx/ 
__sched fork(p); 
/* 设 置 成 


TASK_RUNNING, 其 实 新 创建 的 进程 并 没有 真正 地 在 
CPU 上 执行 ， 
* 此 举 的 目的 是 防止 外 部 信号 和 时 间 将 其 唤醒 ， 之 后 插入 运行 队列 


A 
p->state = TASK RUNNING; 
p->prio = current->normal prio; 
/* 如 果 设置 了 


scheqd_reset_on fork 标 志 位 ,后面 会 讨论 


# 
/ 
if (unlikely(p->sched reset on fork)) { 
if (task has rt policy(p)) { 
p->policy = SCHED NORMAL; 
p->static prio = NICE TO PRIO(0); 
p->rt priority = 0; 
} else if (PRIO TO NICE(p->static prio) < 0) 
p->static prio = NICE TO PRIO(0); 
p->prio = p->normal prio = normal prio(p); 
set_ load weight (p); 
Pp->sched reset cn fork = 0; 


} 
/* 如 果 不 是 实时 进程 ， 则 调度 类 为 完全 公平 调度 类 


4 
if (lrt prio(p->pric)} 
p->sched class = &fair sched class; 
/* 如 果 调度 类 实现 了 


task_fork 函 数 ， 则 调用 该 函数 


4 
if (p->sched class->task fork) 
p->sched class->task fork(p); 








do fork | 


> Copy_process | 




















wake up new task 








西 sched fork 


task fork task fork fair 














activate task 


check_PreemPt_cCUIL 







enqueue task 


enqueue task fair 


check preempt wakeup 




















图 5-13 ”创建 新 进程 中 与 调度 相关 的 函数 


sched_fork 函 数 的 主要 工作 是 初始 化 进程 的 与 调度 相关 的 
执行 与 调度 类 相关 的 函数 。 













































































变量 ， 确 定 进程 所 属 的 调度 类 及 优先 级 设置 。 根 据 进程 所 属 的 调度 类 ， 
与 新 创建 的 进程 相关 的 初始 化 事宜 。 对 于 完全 公平 调度 类 ， 该 函数 的 实 











调度 类 需要 实现 task fork 这 个 hook 函 数 。 该 函数 用 于 处 理 
现 为 : 








task fork task fork fair, 











下 面 一 起 走 进 task fork fair 函 数 来 看 一 下 完全 公平 调度 类 

















是 如 何 处 理 新 创建 的 进程 的 : 














static void tas 
{ 


‘fork fair(struct task struct *p) 


Struct cfs rq *ofs £q = task ofs rq(Lurrent): 

struct sched entity *se = &p->Se, *ceurr cfs rq->curr; 

int this_ cpu smp_processor id(); 

struct rq *rg = this rg(): 

unsigned long flags; 

raw_ spin lock irqsave(&rq->lock, flags); 

update rq clock (rq); 

if (unlikely (task cpu(p) 
rcu read lock(); 
_ set task cpulp, this_cpu); 
rcu read unlock(); 


!= this cpu)) { 


} 


/* 更 新 


CFS 调 度 类 的 队列 


7 包括 执行 


__ update_CurT 更 新 当前 进程 统计 


update_curr (cfs_rq) ; 
/ * 新 创建 进程 的 


Vruntime 初 始 化 成 父 进程 的 


vruntime, 


* 紧 随 其 后 的 


place_entity 函 数 会 负责 调整 新 创建 进程 的 


vruntime*/ 
4 (Gurr) 


se->vruntime = curr->vruntime; 


Blave entity(ofs rg, ser 工 ) 
/* 如 果 设置 了 子 进程 先 运行 ， 并 且 父 进程 的 


VEUntime 小 于 子 进程 ， 则 交换 彼此 的 


VEUntime， 确 保 子 进程 先 执行 


*y 


if (sysctl sched child runs first && curr && entity _ before (Curr，se)) { 


swap (curr->vruntime, se->vruntime); 
resched task (rq->curr); 


5 
/* 此 处 减 去 当前 运行 队列 的 最 小 虚拟 运行 时 间 ， 


* 真 正 进入 运行 队列 ， 即 执行 


enqueue_entity 时 ， 


* 进 程 的 


vruntime 会 加 上 


cfs_rq->vruntime*/ 
Se~>vruntime == cfs rq->min vruntimes 
raw_spin unlock irqrestore(&rq->lock, flags); 


} 





关于 新 进 











程 ， 进 程 调度 领域 有 两 大 悬疑 : 

















新 进程 的 虚拟 运行 时 


.父子 进程 














UD 


哪个 先 执 

















下 面 将 分 别 进行 分 析 。 














间 到 底 是 多 少 ? 


行 ? 


1. 新 创建 进程 的 虚拟 运行 时 间 初 始 值 


task fork _ fair 函数 中 有 以 下 内 容 : 





4 (Gurr) 


se->vruntime = curr->vruntime; 


Plave entity(pfs rq, ser 1)? 





从 上 
































的 函数 中 可 以 看 出 ， 新 创建 子 进程 的 虚拟 运行 时 间 首 先 被 初始 化 成 父 进程 





的 虚拟 运行 时 间 ， 接 下 来 会 调 月 




















数 ， 而 place_entity 函 数 会 调整 新 创建 进程 的 虚拟 运行 时 间 。 


“place_entity”， 直 
通过 调整 





疑问 ， 只 外 























一 





























place_entity 函 数 用 来 处 理 两 种 比较 特殊 的 情况 : 





“调整 新 创建 进程 的 虚 


` 调 整 从 休眠 中 唤醒 进 

















拟 运行 时 间 。 





程 的 虚拟 运行 时 间 。 





月 了 place_entity 函 








的 翻译 就 是 放置 调度 实体 的 意思 ， 即 把 调度 实体 放置 到 合适 的 位 置 。 如 何 才能 决定 调度 实体 的 位 置 呢 ? 毫 无 
周 度 实 体 的 虚拟 运行 时 间 来 实现 。 








这 两 种 情况 根据 该 函 





数 的 第 三 个 参数 initial 来 区 





分 。initial 等 于 1 则 表示 调整 新 创建 进程 的 虚拟 运行 时 间 。 


下 面 来 看 看 place_entity 函 数 是 如 何 调整 新 创建 进程 的 虚拟 运行 时 间 的 ， 代 码 如 下 : 




















= 





static void 
place entityl(struct cfs rq *cfs rq, 


{ 





struct sched entity *se, int initial) 
u64 vruntime = cfs rq->min vruntime; 
if (initial && sched feat (START _DEBIT)) 


vruntime += sched | vslice (cfs, rq, se);.. 


vruntime = max vruntime (se->vruntime, vruntime);se->vruntime = vruntime 
} 

static u64 sched vslicel(struct cfs rq *cfs rq, struct sched entity *se) 
{ 

return calc delta fairl(sched slicel(cfs rq, se), se); 

} 























完全 公平 调度 类 的 运行 队列 cfs_rq 中 维护 有 成 员 变 量 min_vruntime， 该 变量 存放 的 是 此 运行 队列 中 的 最 小 虚拟 运行 时 间 。 就 像 前 面 
， 通 过 它 我 们 无 须 遍 历 队列 上 所 有 进程 的 虚拟 运行 时 间 ， 就 可 以 得 知 该 
进程 的 虚拟 值 在 该 值 附近 ， 且 略 大 于 该 值 。 






































所 说 的 ， 它 提供 了 一 个 基准 值 





玄 运 行 队列 的 整体 情况 了 。 大 多 数 





内 核 提 供 了 很 多 调度 的 特性 











， 记 录 在 /sys/kernel/debug/sched featuresj 





Pp， 如 下 所 示 : 


cat /sys/kernel/debug/sched features 
GENTLE FAIR SLEEPERS START DEBIT 





NO_NEXT BUDDY LAST BUDDY CACHE HOT BUDDY WAKEUP 


PREEMPTION ARCH POWER NO HRTICK NO DOUBLE TICK LB BIAS NONTASK POWER TTWU 
QUEUE NO FORCE SD OVERLAP RT _RUNTIME | SHARE NO_LB MIN NUMA NUMA FAVOUR | HIGHER 
NO_NUMA | RESIST | LOWER 


其 中 START_DEBIT 特 性 是 用 来 给 新 创建 的 进程 略 加 惩罚 的 。 如 果 没 有 START_DEBIT 选 项 ， 子 进 
























































i 





旦 的 虚拟 运行 时 间 为 : 


max ( 父 进程 的 虚拟 运行 时 间 ， 





CES 运 行 队列 的 最 小 运行 时 间 














这 个 值 通常 比较 小 ， 这 就 意味 着 子 ; 

















程 很 快 就 能 获得 调度 的 机 会 ， 因 此 也 就 给 了 恶意 进程 可 乘 之 机 。 因 
地 fork 来 获得 更 多 的 CPU 时 间 。 如 果 设 置 了 START _DEBIT 选 项 ， 会 通过 


为 恶意 进程 可 以 通过 不 停 
了 通过 增 大 子 进程 的 虚拟 运行 时 间 来 惩罚 新 创建 的 进程 ， 使 新 创建 的 
进程 晚 一 点 才能 获得 被 调度 的 机 会 。 






















































































那么 虚拟 运行 时 间 增 大 多 少 呢 ?看 看 下 面 的 语句 : 


vruntime += sched vslicel(cfs rq, se); 





区 


和 面 介绍 过 sched_ slice 函数 是 用 来 计算 进程 的 时 间 片 的 ， 那 么 


| 








么 sched_vslice 函 数 又 是 何 意 呢 ? 


static u64 sthed vslicel(lstruct cfs rg *cfs rg, struct sched entity *se)} 
{ 





return calc delta fairl(sched slicel(cfs rq, se), se); 
} 





sched_vslice 函 数 是 根据 时 间 片 的 值 ， 来 计算 对 应 的 虚拟 时 间 片 的 值 。 即 根据 进程 的 优先 级 来 调整 。j 
了 。 























蛋 整 的 算法 前 面 已 经 提 到 过 

















打开 了 START_DEBIT 特 性 ， 子 进程 的 虚拟 运行 时 间 就 会 被 初始 化 成 : 


max ( 父 进程 的 虚拟 运行 时 间 ， 





CFS 运 行 队列 的 最 小 运行 时 间 


十 进程 虚拟 时 间 片 





2 父子 进程 谁 先 执行 








另 一 大 悬案 是 父子 进程 哪个 会 先 执行 ? 


内 核 提供 了 配置 选项 sched_child runs first， 该 值 记录 在 : 











/proc/sys/kernel/sched child runs first 








是 0， 即 父 进程 优先 执行 。 





task_fork _ fair 函数 中 有 以 下 代码 : 





该 配置 选项 是 1 的 话 ，fork 之 后 子 进程 将 优先 获得 调度 ， 如 果 是 0 的 话 ， 父 进程 将 优先 获得 1 


2.6.32 开 始 ， 该 值 默认 





前 度 。 内 核 版 本 自 





























if (sysctl sched child runs first && curr && entity before (Curr， se)) { 
swap (curr->vruntime, se->vruntime); 


resc. 


上 


ed task (rq->curr); 




















如 果 要 设置 子 进程 优先 获得 调度 ， 则 会 通过 entity before 函数 来 比较 父子 进程 的 vruntime， 如 果 父 进程 的 vruntime 小 ， 则 需要 和 子 进 





























(preference) ， 而 不 是 一 种 保证 〈guarantees) P] 。 在 编写 应 月 





但 是 正如 Linus 在 邮件 1 








得 调度 。 











程 互 换 vruntime 以 确保 子 进程 优先 者 











P 提 到 的 ， 无 论 是 父 进 入 




















好 











的 是 一 种 倾向 或 














呈 先 运行 ， 内 核 控制 选项 提 4 























呈 先 运行 还 是 子 进 各 











不 能 作为 作为 





村 ， 无 论 内 核 参 数 sched_child runs_first 为 何 值 ， 者 








程序 有 





其 他 同步 方法 来 确保 运行 的 次 序 。 












































父 进程 或 子 进 


分 析 完 两 大 悬疑 ， 继 续 分 析 task fork fair 


程 先 运行 的 保证 ， 如 果 需 要 保 说 


F 运 行 次 序 ， 程 序 需要 使 月 








口 右 - 


条 语句 非常 奇怪 ， 该 语句 代码 如 下 : 

















se->vruntime -= cfs_ rq->min vruntime; 








为 何 要 减 掉 运 行 队列 的 最 小 虚拟 运行 时 间 ? 继续 向 下 看 就 可 以 悦 然 大 悟 了 。 
器 结构 上 ， 新 创建 的 进 








(如 图 5-14 所 示 )〉 。 事 实 上 在 对 称 多 处 至 








CPU: 


























行 ， 这 是 多 个 CPU 之 间 负 载 均 衡 的 一 个 良机 。Linux 也 是 这 么 做 的 ， 在 wake_up_new_ task 函数 





月 wake_up_new task 函数 





居 为 在 do_fork 的 末尾 会 调 月 
个 CPU 上 运行 。 进 程 刚 刚 创建 好 ， 尚 未 运 












































程 和 父 进程 不 一 定 在 同 



































bP 会 首先 调用 如 下 语句 ， 选 择 一 个 合适 的 


P| 

















set task cpul(p, select task rgq(p, SD BALANCE FORK, 0)); 








wake up new task 








set task cpu 
Select task rq 
activate task 


enqueue task 












enqueue task fair 


enqueu entity 





check preempt curr 


5-14 ”wake up_new_ task 函数 





很 不 幸 的 是 ， 不 同 的 CPU 之 间 负 载 并 不 完全 相同 ， 有 的 CPU 更 忙 一 些 ， 而 且 每 个 CPU 都 有 自己 的 运行 队列 c&_rq， 不 同 的 CPU 运行 
队列 的 最 小 虚拟 运行 时 间 min_vruntime 并 不 相同 。 如 果 新 创建 的 进程 从 一 个 CPU 的 运行 队列 迁移 到 另外 一 个 CPU 的 运行 队列 ， 就 可 能 会 


产生 问题 。 比 如 新 
在 相当 长 的 时 间 范 





























创建 的 进程 从 min_vruntime 小 的 CPU A 跳 到 min_vruntime 非 常 大 的 CPUB， 它 就 会 占便宜 ， 因 为 它 的 虚拟 运行 时 间 会 
围 内 都 是 最 小 的 ， 从 而 产生 调度 的 不 公平 。 











解决 的 方法 非常 简单 : 





迁移 前 : 


进程 的 虚拟 运行 时 间 


三 迁移 前 所 在 


CPU 运行 队列 的 最 小 虚拟 运行 时 间 


迁移 后 : 


进程 的 虚拟 运行 时 间 


二 二 迁移 后 所 在 


CPU 运行 队列 的 最 小 虚拟 运行 时 间 
































enqueue task 也 是 调度 类 的 hook 函 数 ， 每 一 个 调度 类 都 要 实现 该 函数 ， 对 于 完全 公平 的 调度 而 言 : 








‘enqueue task 


= enqueue task fair, 








在 enqueue task fair 函 数 中 ， 会 调用 enqueue_entity 函 数 ， 在 该 函数 中 有 以 下 语句 和 task fork fair 函 数 相 呼应 : 





static void task fork fair(struct task struct *p) 
{se->vruntime -= cfs rq->min vruntime; 


} 
static void 
enqueue entityl(struct cfs rq *cfs rq, struct sched entity *se, int flags) 
{ 
...if (!(flags & ENQUEUE WAKEUP) || (flags & ENQUEUE WAKING)) 
se->vruntime += cfs rq->min vruntime;... 


} 





























出 | 























和 实 上 该 解决 方案 不 仅仅 只 是 用 于 新 创建 的 进程 这 一 个 场景 。Linux 支 持 CPU 之 间 的 负载 均衡 ， 可 以 将 进程 从 一 个 CPU 迁 移 到 另外 
一 个 CPU， 为 了 防止 不 公平 的 产生 ， 也 采用 了 上 述 的 解决 方案 。 











static void 
dequeue entity(struct cfs rq *cfs rq, struct sched entity *se, int flags) 


if (!(flags & DEQUEUE SLEEP)) 
se->vruntime -= cfs_ rq->min vruntime; 


} 

static void 

enqueue entityl(struct cfs rq *cfs rq, struct sched entity *se, int flags) 
{ 


if (!(flags & ENQUEUE WAKEUP) || (flags & ENQUEUE WAKING)) 
se->vruntime += cfs rq->min vruntime;... 
} 














六 


创建 新 的 进程 不 仅 是 CPU 之 间 负 载 均 衡 的 良机 ， 也 是 检测 是 否 可 以 发 生 抢 占 的 良机 。 因 此 ，wake_up_new_task 在 最 后 会 调用 
check_preempt_curr 岗 数 。 该 函数 会 负责 检查 可 否 抢 占 当 前 的 运行 进程 。 这 个 函数 的 详细 内 容 ， 将 放 到 下 一 节 来 分 析 。 






































Tt 














[1] Re:[GIT PULL]|sched/core for v2.6.32:http://thread.gmane.org/gmane.linux.kernel/888423/focus=888543。 
[2] http://stackoverflow.com/questions/17391201/does-proc-sys-kernel-sched-child-runs-first-work。 


5.4.4 睡眠 进程 醒 来 

















睡眠 进程 的 虚拟 运行 时 间 会 保持 不 变 吗 ? 





































































































体 消耗 并 不 大 ， 但 是 要 求 响应 必须 及 时 ， 否 则 用 户 会 感觉 到 系统 卡 顿 ， 用 户 体 验 就 会 很 糟糕 。 















































如 何 对 待 睡眠 进程 也 是 调度 器 需要 解决 的 问题 。 因 为 交互 型 的 进程 会 不 断 陷 入 休 眼 状态 中 ， 并 等 待 用 户 的 输入 。 虽 然 这 类 进程 对 CPU 的 整 


对 CFS 之 前 的 O (1) 调度 器 来 说 ， 交 互 型 进程 堪 称 其 阿 喀 琉 斯 之 踊 。 该 调度 算法 的 交互 进程 识别 启发 式 算法 异常 复杂 ， 该 启发 式 算 法 融入 



































眠 时 间作 为 考量 的 标准 ， 但 是 对 于 一 些 特殊 的 情况 ， 经 常 判断 不 准 ， 而 且 经 常 是 改 完 一 种 情况 又 发 现 男 一 种 特殊 情况 。 
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CFS 调 度 算法 并 没有 
呢 ， 对 于 从 休眠 中 醒 来 的 进程 ，CFS 进 行 了 哪些 处 理 呢 ? 这 是 本 节 要 介绍 的 内 容 。 
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是 default wake_function。 该 函数 是 try to_wake_up 的 简单 封装 ， 因 此 当 进 程 被 内 核 唤醒 时 ， 内 核 通 常会 执行 ty _ to_wake_up 函 数 。 








概括 地 讲 ，try to_ wake_ up 函数 的 职责 是 : 








1) 把 从 休眠 中 醒 来 的 进程 放 到 合适 的 运行 队列 。 

















2) 将 进程 的 状态 设置 为 TASK_RUN-NING。 









































3) 判断 醒 来 的 进程 是 否 应 该 抢占 当前 正在 运行 的 进程 ， 如 果 是 ， 则 设置 need_resched 标 志 位 。 
































try_to_wake_up 的 部 分 流程 如 图 5-15 所 示 。 


try_ to wake up 









ttwu do activate 


ttwu activate 









ttwu do wakeup 








图 5-15 try to_wake_up 函 数 
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， 分 别 由 以 下 函数 负责 完成 ， 如 表 5-4 所 示 。 





前 面 提 到 的 try to_wake_ up 负责 的 三 件 寻 


























表 5-4 try_to_wake_up 三 个 主要 任务 及 对 应 的 负责 函数 








事 件 相关 函数 
将 醒 来 的 进程 放 入 合适 的 运行 队列 中 ttwu activate 
设置 进程 状态 为 TASK_RUNNING ttwu_do_wakeup 
判断 唤醒 进程 能 否 抢占 当前 的 进程 ， 是 则 置 need_resched ttwu_do_wakeup 








首先 来 看 看 ttwu_active 函 数 的 相关 内 容 : 


static void ttwu activate(struct rq *rq, struct task struct *p, int en flags) 
{ 


activate task(rg, p, en flags); 
p->on rq = 1; 加 
/* if a worker is waking up, notify workqueue */ 
if (p->flags & PF WO WORKER) 

Wwq_worker waking up(p, cpu of (rq)); 


} 
static void activate task(struct rq *rq, struct task struct *p, int flags) 
{ 


睡眠 进程 和 等 待 队 列 的 关系 在 5.1 节 已 经 介绍 过 。 当 内 核 调 用 wake_up 系 列 宏 时 ， 会 执行 运行 队列 元 素 中 指定 的 回调 函数 ， 而 回 
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I 意 地 区 分 交互 型 进程 和 批 处 理 型 进程 ， 依 然 漂亮 地 满足 了 交互 型 进程 需要 及 时 响应 的 需求 。CFS 算 法 是 如 何 做 到 的 


球 


if (task contributes to load (P) ) 
rq->nr uninterruptible——» 
/* 将 进程 插入 运行 队列 ， 


enqueue task 是 调度 类 
hook 函 数 


4 
enqueue task(rq, p, flags); 


} 

static void enqueue task(struct rq *rq, struct task struct *p, int flags) 
1 
update rq clock (rq); 
sched info queued (p); 
/* 根 据 进程 所 属 的 调度 类 ， 执 行 相应 的 


enqueue _ task 函数 


wi 
p->sched class->enqueue task(rgq, p, flags); 
. 








其 执行 脉络 如 图 5-16 所 示 。 


ttwu activate 
activate task 


enqueue task 

























engqueue task fair 





图 5-16 ”ttwu activate 函 数 








activate_ task 函数 和 deactivate_ task 函数 一 样 ， 都 是 调度 框架 内 的 
程 调 用 wait_event 时 ， 进 程 从 可 运行 状态 变 成 睡眠 状态 ， 因 出 
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EE 要 函数 ， 并 且 两 者 是 一 对 ， 就 好 像 wake_up 和 wait_event 是 一 对 一 样 。 当 进 
需要 通过 deactivate_task 函 数 将 进程 从 运行 队列 中 移 除 ， 与 此 对 应 的 ， 当 内 核 i 
wake_up 函 数 把 进程 从 休眠 状态 唤醒 时 ， 内 核 需 要 通过 activate_task 函 数 将 进程 放 入 运行 队列 中 。 如 果 对 5.4.3 节 创建 新 进程 还 有 印象 的 话 ， 可 以 
看 到 无 论 是 创建 新 进程 ， 还 是 唤醒 休眠 进程 ， 都 会 执行 到 该 函数 ， 如 图 5-17 所 示 。 
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进程 从 休眠 中 醒 来 创建 新 进程 


ttwu activate 









wake up new task 


activate task 


enqueue task 









enqueue task far 
enqueu entity 


图 5-17 ”activate 函 数 相关 流程 
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中 enqueue_task 函 数 是 调度 类 的 hook 函 数 ， 每 个 调度 类 都 需要 实现 该 函数 。 其 含义 顾名思义 ， 即 将 进程 放 入 运行 队列 。 对 于 完全 公平 1 
类 而 言 ， 该 函数 指针 指向 的 是 enqueue_task_fair， 代 码 如 下 : 
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.enqueue task = enqueue task _ fair， 






































enqueue_ task 人 fair 很 大 部 分 的 工作 是 更 新 调度 相关 的 统计 ， 其 中 有 一 支 代 码 路 径 非常 有 意思 《如 图 5-18 所 示 ) ， 下 面 将 重点 
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| enqueue entity 






place entity 





图 5-18 ”CFS 的 enqueue_task fair 函数 








这 条 路 径 之 所 以 很 重要 ， 是 因为 它 决 定 了 休眠 进程 醒 来 后 的 虚拟 运行 时 间 。 回 到 本 节 开 头 的 问题 : 休眠 进程 的 虚拟 运行 时 间 会 保持 不 变 
吗 ? 答案 是 否定 的 。 很 多 进程 可 能 会 长 时 间 地 休眠 ， 在 这 个 过 程 中 ， 如 果 虚 拟 运 行 时 间 vruntime 保 持 不 变 ， 一 旦 该 进程 醒 来 ， 它 的 vruntime 就 会 
比 运 行 队列 上 的 其 他 进程 小 很 多 ， 因 为 会 长 时 间 保 持 调度 的 优势 。 这 显然 是 不 合理 的 。 对 于 这 种 情况 ， 完 全 公平 调度 的 做 法 是 ， 以 运行 队列 的 
































min_vruntime 为 基础 ， 给 予 一 定 的 补偿 。 






































补偿 多 少 ? 这 就 又 要 去 看 看 我 们 的 老 朋 友 place_entity 函 数 了 。 在 创建 新 进程 时 ， 曾 经 走 到 过 该 函数 ， 那 时 该 函数 负责 决定 新 进程 的 虚拟 运 




















行 时 间 。 下 面 来 看 看 对 于 被 唤醒 的 休眠 进程 ， 该 函数 是 如 何 决 定 进程 的 虚拟 运行 时 间 的 : 








static void 
blace entityt(struct cfs rq *efs rq; struet sched entity *sey int initial) 


u64 vruntime = cfs rq->min vruntime; 


/六 从 休眠 中 醒 来 


if (!initial) { 
/* 补 偿 一 个 调度 周期 


unsigned long thresh = sysctl] sched latency; 
/* 如 果 设置 了 


GENTLE_FAIR_SLEEPERS, 则 补偿 半 个 调度 周期 


if (sched feat (GENTLE FAIR SLEEPERS)) 
thresh >>= 1; 
vruntime -= thresh; 


vruntime = max vruntime (se->vruntime, vruntime); 
se->vruntime = vruntime; 


E 

















当 initial 等 于 0 时 ， 表 示 正 在 处 理 从 休眠 中 醒 来 的 进程 。 如 果 没 有 设置 GENTLE FAIR SLEEPERS 特 性 ， 那 么 在 队列 最 小 虚拟 运行 时 间 的 基础 












































上 ， 补 偿 1 个 调度 延迟 ， 如 果 设 置 了 GENTLE FAIR SLEEPERS， 那 么 补偿 减 半 ， 即 补偿 
的 特性 是 打开 的 。 





























个 调度 延迟 。 默 认 情 况 下 ，GENTLE_ FAIR_ SLEEPER 





但 休眠 进程 醒 来 后 的 虚拟 运行 时 间 并 非 只 是 简单 粗 景 地 设置 成 队列 的 最 小 运行 时 间 减 掉 补 偿 值 。 影 响 因 素 还 有 进程 原本 的 虚拟 运行 时 间 ， 











如 下 所 示 : 














vruntime = max vruntime (se->vruntime, vruntime); 


















































如 果 体 眠 进程 的 睡眠 时 间 非 常 短 ， 很 有 可 能 进程 原本 的 虚拟 运行 时 间 要 大 于 上 述 计 算得 到 的 值 ， 此 时 ， 休 卢 进 程 的 虚拟 运行 时 间 不 变 ， 即 








为 睡眠 前 的 值 。 如 果 休 眠 进程 的 睡眠 时 间 特 别 久 ， 醒 来 时 已 经 沧海 桑田 ， 那 么 就 将 虚拟 运行 时 间 设 置 为 所 在 运行 队列 的 最 小 虚拟 运行 时 间 减 去 














补偿 量 。 























从 上 面 的 代码 可 以 看 出 ， 从 长 时 间 休眠 中 醒 来 的 进程 ， 因 为 其 虚拟 运行 时 间 较 小 《〈 比 队列 的 最 小 虚拟 运行 时 间 还 小 ) ， 所 以 会 获得 优先 的 






































调度 ， 从 而 使 交互 型 进程 得 到 及 时 的 响应 。 














四 
@,, 这 种 对 休眠 进程 进行 奖励 的 做 法 ， 在 进程 调度 设计 领域 存在 一 定 的 争议 。 内 核 进程 调度 领域 的 大 牛 Con Kolivas 就 坚持 认为 ， 
调度 器 只 需要 向 前 看 ， 而 不 应 该 考虑 一 个 进程 的 过 去 。 在 早期 的 CFS 调 度 算法 (版 本 2.6.23〉 中 ，CFS 会 负责 记录 进程 的 sleep time，2.6.24 版 本 之 

































































后 的 内 核 ， 就 不 再 考虑 进程 过 去 的 睡眠 时 间 了 。 























但 是 CFS 做 得 





不 彻底 ， 在 place_entity 函 数 








FP， 对 休眠 进 






























































Fm es 


















































程 进行 了 补偿 。 在 CFS 早 期 的 版 本 中 ，sleeper fairness 的 特性 会 导致 在 一 些 情况 下 
现 严 重 的 调度 延迟 。 在 Jens Axboe 的 测试 中 中 ， 甚 至 会 出 现 10 秒 的 延迟 ， 也 有 客户 报告 在 编译 内 核 时 ， 音 频 视 频 会 有 严重 的 停顿 。 上 面 代 码 中 
的 GENTLE FAIR_SLEEPER 特 性 就 是 作者 Ingo 给 出 的 Patch， 这 个 特性 解决 了 10 秒 的 延迟 和 








其 他 鼠标 滞后 、 视 频 停 顿 等 交互 性 的 问题 。 





[1] Re: BFS vs.mainline scheduler benchmarks and measures:http://Ilwn.net/Articles/352875/。 


5.4.5 ”唤醒 抢占 























无 论 是 try to_wake_up 唤 醒 睡 眠 的 进程 还 是 wake_up_new_task 负 醒 新 创建 的 进程 ， 内 核 都 会 使 用 check preempt curr 函 数 来 检查 新 唤醒 
的 进程 或 新 创建 进程 是 否 可 以 抢占 当前 运行 的 进程 ， 如 图 $-19 所 示 。 


GneekeoneempEERcCO 


图 $-19 ”唤醒 抢占 













































































间断 是 否 应 该 抢占 的 工作 被 委托 给 了 check_preempt_curr 函 数 来 完成 。 








static void check preempt curr(struct rq *rq, struct task struct *p, int flags) 
{ 


Const struct sched class *class; 

if (p->sched class == rq->curr->sched class) { 
rq->curr->sched class->check preempt currl(rq, p, flags); 

} else {/*for each class， 从 高 优先 级 的 调度 类 到 低 优先 级 的 调度 类 


Wh 
for each class(class) { 
/* 如 果 候选 进程 的 调度 类 低 于 当前 进程 所 属 的 调度 类 ， 就 直接 跳出 。 


不 许 低 优 先 级 的 调度 类 抢占 高 优先 级 的 调度 类 


Wh 
if (class == rq->curr->sched classe) 
break; 
/* 如 果 候选 进程 所 属 的 调度 类 优先 级 高 于 当前 进程 的 调度 类 ， 


则 通过 执行 


resched_ task 函数 , 设置 


need_rescheq 标 志 位 


下 
if (class == p->sched class) { 
resched task (rq->curr); 
break; 


} 

* 

if (rq->curr->on rq && test tsk need resched (rq->curr) 
raq->Bkip clock update = 1} 
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判断 能 否 发 生 抢占 的 逻辑 异常 简单 ， 也 是 符合 正常 人 思维 的 : 
































“如 果 候 选 进程 和 正在 运行 的 进程 属于 同一 个 调度 类 ， 那 么 调度 类 内 部 提供 方法 解决 。 





















































“如 果 候 选 进程 和 正在 运行 的 进程 属于 不 同 的 调度 类 ， 候 选 进程 所 属 调度 类 的 优先 级 高 于 正在 运行 进程 的 调度 类 的 优先 级 ， 则 可 以 抢 
， 和 否则 不 可 以 。 






































注意 新 唤醒 的 进程 不 一 定 是 普通 进程 ， 也 可 能 是 实时 进程 。 如 果 唤 醒 的 进程 是 实时 进程 而 当前 运行 的 进程 为 普通 进程 ， 则 会 设置 
need_resched 标 志 位 ， 因 为 实时 进程 总 是 会 抢占 CFS 调 度 域 的 普通 进程 。 





































































































每 一 种 调度 类 都 应 该 实现 自己 的 check preempt cur 函 数 来 判断 是 否 需要 发 生 抢 占 ， 对 于 完全 公平 调度 类 ，check preempt_cur 的 实现 为 


check preempt wakeup 函 数 。 





.Check preempt curr = check preempt wakeup, 












































必 


平 调度 类 ， 那 么 候选 进程 到 底 会 不 会 抢占 当前 运行 的 进程 呢 ? 哪些 因素 会 影响 到 抢占 行 








如 果 候 选 进程 和 正在 运行 的 进程 都 属于 完 4 
为 呢 ? 
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如 果 被 唤醒 的 进程 的 睡眠 时 间 非 常 久 《上 百 毫 秒 、 几 百 毫 秒 、 几 秒 甚 至 更 久 ) ， 前 面 的 place_entity 函 数 会 将 睡眠 进程 的 虚拟 运行 时 间 
设置 为 队列 的 最 小 虚拟 运行 时 间 减 掉 补 偿 的 半 个 调度 周期 ， 这 会 使 睡眠 进程 的 虚拟 运行 时 间 非 常 的 小 ， 醒 来 时 几乎 总 是 会 抢占 当前 的 进 
程 ， 这 种 行为 也 是 期 待 的 行为 ， 因 为 它 可 以 保证 交互 型 进程 的 响应 时 间 。 
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但 是 也 有 很 多 进程 的 睡眠 时 间 非 常 短 暂 〈 比 如 只 有 几 毫 秒 甚 至 更 短 ) ， 醒 来 之 后 通过 place_entity 函 数 计算 得 出 的 虚拟 运行 时 间 值 仍然 
是 自己 本 来 的 虚拟 运行 时 间 值 。 如 果 仅 仅 比较 醒 来 的 进程 和 当前 运行 进程 的 虚拟 运行 时 间 来 诀 定 是 否 抢占 ， 那 么 很 可 能 会 使 得 抢占 过 于 频 
繁 [0 。 因 此 Linux 引 入 了 唤醒 抢占 粒度 sched_wakeup_granularity_ ns， 可 以 通过 如 下 方法 来 查看 系统 的 唤醒 抢占 粒度 
sched_ wakeup_granularity ns 的 值 : 



































































































































cat /proc/sys/kernel/sched wakeup granularity ns 
2000000 























引入 该 最 小 粒度 后 ， 唤 醒 进 程 抢占 当前 进程 的 条 件 是 : 只 有 当 唤 醒 进 程 的 vruntime 小 ， 并 且 两 者 的 差 值 vdiff 大 于 
sched_wakeup_granularity_ns 时 ， 才 能 抢占 。 具 体 的 算法 实现 如 下 : 


















































static int 
wakeup preempt entity(struct sched entity *curr, struct sched entity *se) 


s64 gran, vdiff = curr->vruntime - se->vruntime; 
if (vdiff <= 0) 
et 二 
gran = wakeup gran (CUFT， se); 
if (vdiff > gran) 
return 1; 
return 0; 
} 
static unsigned long 
wakeup gran(struct sched entity *curr, struct sched entity *se) 


unsigned long gran = sysctl sched wakeup granularity; 
return calc delta fair(gran: Be) 
} 


























如 果 系 统 的 唤醒 抢占 太 过 频繁 ， 大 量 的 上 下 文 切换 会 影响 系统 的 整体 性 能 。 这 种 情况 下 可 以 通过 调整 Sched_wakeup_granularity_ns 的 值 
来 解决 ，sched_wakeup_granularity_ns 的 值 越 大 ， 发 生 唤醒 抢占 就 越 不 容易 。 注 意 sched_wakeup_granularity_ns 的 值 不 要 超过 调度 周期 
sched_latency_ns 的 一 半 ， 否 则 的 话 ， 就 相当 于 禁止 唤醒 抢占 了 。 






























































[1] 从 几 个 问题 开始 理解 CFS 调 度 器 : http://linuxperf.com/?p=42。 





$.$ 普通 进程 的 组 调度 


完全 公平 调度 算法 会 尽力 在 进程 之 间 保 证 公平 。 如 果 有 50 个 优先 级 相同 的 进程 ，CFS 会 努力 让 每 个 
进程 获得 的 CPU 时 间 为 2%， 以 确保 公平 。 








可 是 考虑 一 下 如 图 $-20 所 示 的 场景 。 


表面 看 每 个 进程 都 被 进程 调度 器 公平 对 待 了 ， 即 4 个 进程 每 个 都 获得 了 25% 的 CPU 时 间 。 但 是 其 中 
的 用 户 B 并 没有 得 到 公平 的 对 待 。 我 们 将 情况 考虑 得 再 极端 一 点 : 系统 上 存在 50 个 进程 ， 其 中 49 个 都 属 
于 用 户 A， 而 用 户 B 只 有 1 个 进程 。 那 么 对 于 用 户 B 而 言 ， 它 只 能 使 用 2% 的 CPU 资源 ， 这 显然 是 不 公平 
的 。 











比较 合理 的 做 法 是 ， 首 先 确保 组 间 的 公平 ， 然 后 才 是 组 内 进程 之 间 的 公平 ， 如 图 5-21 所 示 。 





用 户 A 用 户 B 
= 
Fa: RE BE . 
25% ! 25% ! 25% ! 25% 
CPU 资源 





图 5-20 没有 组 调度 时 的 表面 公平 





用 户 A 用 户 B 

Groupl Group2 

50% | 50% 

, | | 进程 4 

16.7% '! 167% '! 167% '! 50% 
CPU 资 源 


图 5-21 引入 组 调度 后 


Linux 内 核实 现 了 cgroups 《control groups 的 缩写 ) 功能 ， 该 功能 用 来 限制 、 记 录 和 隔离 一 个 进程 组 
群 所 使 用 的 物理 资源 (如 CPU、 内 存 、 磁 盘 IO、 网 络 等 ) 。 为 了 管理 不 同 的 资源 ，cgroups 提 供 了 一 系 








列子 系统 ， 本 节 将 要 介绍 的 cpu 和 后 面 CPU 亲和力 一 节 介绍 的 cpuset 都 属于 cgroups 的 子 系统 。cpu 子 系统 
只 用 于 限制 进程 的 CPU 使 用 率 。 接 下 来 介绍 如 何 使 用 cgroups 的 cpu 子 系统 来 创建 组 〈task group) 及 按 组 
来 分 配 CPU 资源 。 





首先 需要 挂 载 和 安装 cgroup 文 件 系统 ， 挂 载 时 需要 局 用 CPU 资源 控制 : 





mount -t cgroup -o cpu none /cgroup/cpu/ 





在 /cgroup/cpu 目 录 下 创建 两 个 目录 : GroupA 和 GroupB， 这 样 就 会 创建 两 个 进程 组 群 。 





mkdir /cgroup/cpu/GroupA 
mkdir /cgroup/cpu/GroupB 








目录 创建 完毕 后 ， 可 以 看 到 /cgroup/cpu/GroupA 和 /cgroup/cpu/GroupB 目 录 下 都 已 经 存在 了 很 多 文 
件 ， 如 图 5-22 所 示 。 


rootGmanu- I EAS el A AC 


Jan : ed 

Jan > Sax 

Jan : cgroup.clone children 
Jan > cgroup.event control 
Jan : cgroup.procs 

Jan ] cpu.cfs period us 

Jan cpu.cfs quota us 

Jan 3 cpu.shares 

Jan :43 cpu.stat 

Jan b notify on _ release 


root root 
root root 
root root 
root root 
root root 


root root 
root root 
rOOt Foat 
root ole 
root root © Jan : tasks 
root@manu- EA eA A 国 


DODDTODTODTODOO 


2 
4 
1 
1 
二 省 主 
- 1 root root 
1 
1 
1 
1 





图 5-22 ”task group 下 的 配置 文件 


只 需要 向 GroupA 的 tasks 文 件 中 写 入 进程 ID， 该 进程 就 成 为 了 GroupA 的 成 员 ， 当 该 进程 创建 子 进程 
时 ， 子 进程 也 会 自动 成 为 GroupA 中 的 成 员 。 下 面 进 行 一 个 简单 的 实验 ， 使 用 cgroups 的 cpu 子 系统 来 实现 
分 组 之 间 公 平地 使 用 CPU 资源 。 


首先 打开 一 个 终端 ， 将 shell 进 程 的 PID 写 入 GroupA 的 tasks 文 件 中 ， 在 该 终端 上 通过 stress 命 令 ， 了 唤 
起 4 个 进程 执行 死 循环 ， 消 耗 CPU 资 源 。 





echo $$ > (O/B rou Casks 
stress -c 





此 时 可 以 看 到 ，/cgroup/cpwGroupA/tasks 中 ， 已 经 存在 多 个 进程 ， 它 们 是 bashj 进 程 和 stress 进 程 。 其 
中 stress 进 程 有 5 个 : 1 个 几乎 不 消耗 CPU 资源 的 管理 进程 和 4 个 消耗 大 量 CPU 资源 的 死 循环 进程 。 因 为 该 
shell 中 除了 stress 之 外 ， 并 无 需要 消耗 CPU 的 其 他 进程 ， 所 以 4 个 stress 进 程 消耗 了 几乎 所 有 它 能 使 用 的 











CPU 资源 。 


同时 在 另 一 个 终端 上 ， 将 shell 进 程 的 PID 写 入 GroupB， 同 时 通过 stress 命 令 ， 唤 起 两 个 进程 执行 死 
循环 消耗 CPU 资源 ， 方 法 如 下 : 





echo $$ > /cgroup/cpu/GroupB/tasks 
stress - 


包 记 





通过 ps 命令 查看 stress 相 关 进 程 消耗 CPU 的 情况 ， 如 图 5-23 所 示 。 


rootGmanu- rush :~# ps -C stress -0 pid,cgroup,%cpu,cmd 
PID CGROUP %CPU CMD 
2917 2:cpu:VGroupB .0 stress 
2918 :CpuU:VGroupB stress 
2919 :CDpU:VGroupB stress 
2920 :CDU:VGroupA stress 


2922 

2923 

2924 
elel ullitald 


stress 
stress 
SEEeSSs 


:CpuU:VGroupA 
:CDpU:VGroupA 
:CpU:VGroupA 
-rush :~## 国 


1 1 1 1 it 1 1 
人 
已 卢 了 卢 上 上 NINDID 


六 5 
2 1 
2 .0 
2921 2:cpu:/VGroupA .3 stress 
2 5 
9 6 
2 4 
U 





5-23 ”GroupA 和 GroupB 下 进程 的 CPU 使 用 情况 (1) 


可 以 看 到 一 共有 6 个 消耗 CPU 的 stress 进 程 ， 共 有 2 个 CPU 核 。 平 均 来 说 ， 每 个 stress 进 程 的 使 用 率 应 
该 在 33% 左 右 ， 但 是 事实 并 非 如 此 ，GroupB 的 2 个 进程 共 消 耗 了 约 100% 的 CPU 资源 ， 同 时 GroupA 的 4 个 
进程 共 消 耗 了 约 100% 的 CPU 资源 。 真 正 做 到 了 兼顾 组 间 公 平和 组 内 公平 。 








在 完全 公平 调度 域内 ， 进 程 有 优先 级 ， 高 优先 级 的 进程 享有 更 多 的 CPU 时 间 。 能 否 让 组 与 组 之 间 
也 存在 优先 级 差异 ， 比 如 GroupB 占 用 的 CPU 时 间 是 GroupA 的 2 倍 ? 











答案 是 肯定 的 。 每 一 个 组 内 都 有 cpu.shares 文 件 ，cpu.shares 的 值 默认 是 1024， 和 普通 进程 默认 优先 
级 对 应 的 权重 (NICE 0 LOAD) 是 一 样 的 。 这 说 明 进 程 调 度 会 将 整个 组 看 成 是 1 个 普通 进程 来 分 配 CPU 








下 面 调整 GroupB 的 cpu.shares 的 值 ， 将 其 调整 为 2048 (GroupA cpu.shares 值 的 两 倍 ) ， 然 后 重复 上 
面 的 实验 ， 绪 果 如 图 5-24 所 示 。 


可 以 看 出 GroupB 中 的 两 个 死 循环 消耗 了 133% 的 CPU， 而 GroupA 中 的 4 个 死 循环 只 消耗 了 66% 左 碳 
的 CPU， 两 者 的 比例 约 等 于 2 : 1， 符 合 cpu.shares 中 的 比例 。 


jt 


O 注意 “cpu.shares 的 默认 值 是 1024， 此 时 系统 将 整个 组 内 的 所 有 进 种 





视 为 一 个 普通 进程 。 如 


果 系 统 内 存在 大 量 CPU 消 耗 型 普通 进程 ， 它 们 不 在 任何 组 内 ， 而 组 内 的 进程 数 又 很 多 ， 那 么 组 内 的 进 


程 其 实处 于 被 损害 的 地 位 。 此 时 需要 妥善 调整 cpu.shares 的 值 。 





root@manu-rush:~# ps -C stress -0 pid,cgroup,%cpu,cmd 
PID CGROUP 


3631 
3632 
3633 
3634 


3635 
3636 
3637 
3638 
root@manu - 


5-24 ”GroupA 和 GroupB 下 进程 的 CPU 使 用 情况 (2) 


Us 
:Cpu 
Ses 
:cpu: 
:Cpu: 
:Cpu: 
:Cpu 
iE 


/GroupA 


:VYVGroupA 


/GroupA 
/GroupA 
/GroupA 
PA 


:VGroupB 


/GroupB 


rush:~# 国 


CMD 

stress 
stress 
stress 
stress 
stress 
SEEeSS 
stress 
stress 


NODDBDBSPDPDD 





5.6 ”实时 进程 








对 于 普通 进程 来 说 ， 完 全 公平 调度 已 经 能 够 提供 足够 好 的 性 能 和 响应 体验 了 。 但 是 某 些 进程 对 实 
时 性 的 要 求 更 高 。 严 格 说 来 实时 系统 可 以 分 成 两 类 : 硬 实时 进程 和 软 实 时 进程 。 




















硬 实时 进程 对 响应 时 间 的 要 求 非常 严格 ， 必 须 保证 在 一 定 的 时 间 内 完成 ， 超 过 时 间 限 制 就 会 失 
败 ， 而 且 后 果 非 常 严重 。 这 类 应 用 典型 的 例子 有 军用 武器 系统 、 航 空 航天 系统 、 交 通 导 航 系统 、 医 疗 
设备 等 。 硬 实时 的 关键 特征 是 任务 必须 在 可 保证 的 时 间 范 围 内 得 到 处 理 。 当 然 这 并 不 意味 所 要 求 的 时 
间 范 围 特别 短 ， 而 是 系统 必须 保证 绝 不 会 超过 某 一 时 间 范 围 ， 无 论 当 时 系统 的 负载 如 何 。 主 流 内 核 的 
Linux 并 不 支持 硬 实时 进程 ， 当 然 有 些 修改 版 本 提供 了 该 特性 。 
































软 实 时 进程 是 硬 实时 的 一 种 弱化 形式 。 尽 管 软 实时 进程 仍然 需要 快速 响应 和 要 在 规定 的 时 间 内 完 
成 ， 但 是 超过 了 时 间 的 范围 也 不 会 有 什么 灾难 性 的 后 果 。 比 较 典 型 的 例子 是 视频 处 理应 用 ， 如 果 超 过 
了 操作 时 限 ， 则 会 影响 用 户 体验 ， 但 是 少量 的 丢 帧 还 是 可 以 忍受 的 。 











5.6.1 ”实时 调度 策略 和 优先 级 



































Linux 提 供 了 两 种 实时 调度 的 策略 :先进 先 出 〈SCHED FIFO) 策略 和 时 间 片 轮转 (SCHED RR) 策略 。 无 论 进程 使 用 
哪 种 实时 策略 ， 其 优先 级 都 会 高 于 前 面 介 绍 的 采用 完全 公平 调度 的 普通 进程 。 





























实时 进程 也 有 一 个 优先 级 的 范围 。SUSv3 要 求 至 少 要 为 实时 策略 实现 32 个 离散 的 优先 级 。Linux 中 为 实时 进程 提供 了 99 
个 实时 优先 级 。 从 内 核 层面 看 ， 从 0 到 99 范 围 内 的 优先 级 属于 实时 调度 范围 ， 从 100 到 139 共 40 个 等 级 属于 前 面 讨论 过 的 完 
全 公平 调度 的 优先 级 。 其 中 创建 普通 进程 的 时 候 ， 其 优先 级 的 值 为 完全 公平 调度 中 的 中 间 值 120。 从 整体 来 看 ， 优 先 级 的 
值 越 低 ， 其 优先 级 就 越 高 。 

















































































































事实 上 每 个 CPU 都 有 实时 运行 队列 。 根 据 99 种 离散 的 优先 级 可 知 ， 共 有 99 个 队列 。 具 有 相同 优先 级 的 实时 进程 都 保存 
在 一 个 队列 之 中 。 这 使 得 在 实时 调度 类 中 选择 下 一 个 运行 的 进程 也 就 比较 简单 了 ， 按 照 优 先 级 从 高 到 低 的 顺序 ， 选 择 存在 
可 运行 进程 的 最 高 优先 级 队列 中 的 第 一 个 进程 即 可 《〈 如 图 $-25 所 示 ) 。 事 实 上 内 核 中 还 维护 有 位 图 来 表征 哪个 优先 级 的 运 
行 队列 有 可 运行 的 进程 ， 相 关 结 构 体 定义 如 下 : 



















































































struct rt prio array { 
DECLARE BITMAP (bitmap, MAX RT PRIO+1); /* include 1 bit for delimiter */ 
struct list head queue[MAX RT PRIO]; 


}; 
struct rt rq { 
struct rt prio array active; 





进程 
RR 
了 


进程 3 
RR 
9 








图 $-25 ”实时 进程 的 优先 级 队列 








© 注意 ”对 于 实时 进程 而 言 ， 内 核 态 的 优先 级 和 用 户 进程 通过 sched_setscheduler 或 sched_setparam 系 统 调用 设置 
的 优先 级 并 不 相同 : 对 于 内 核 态 而 言 ， 优 先 级 的 值 越 小 ， 优 先 级 就 越 高 ， 而 用 户 进程 通过 系统 调用 设置 的 优先 级 正好 相 
反 ， 优 先 级 的 值 越 大 ， 优 先 级 越 高 。 两 者 的 换算 关系 是 : 









































内 核 态 优先 级 二 MAX RT_PRIO 一 1 一 用 户 态 优先 级 





其 中 MAX RT PRIO 的 值 为 100。 


1.SCHED FIFO 策 略 























SCHED_FIFO 策 略 是 一 种 比较 简单 的 策略 ， 即 先进 先 出 ， 它 没有 时 间 片 的 概念 ， 只 要 没有 更 高 优先 级 的 进程 就 绕 ， 使 
用 该 调度 策略 的 进程 就 会 一 直 执行 。 一 旦 一 个 调度 策略 为 SCHED FIFO 的 进程 获得 了 CPU 控制 权 ， 它 就 会 始终 占有 CPU 资 
源 直到 下 面 的 某 种 情况 发 生 : 





































































































:自动 放弃 CPU 资源 ， 如 执行 了 一 个 阻塞 型 的 系统 调用 或 调用 了 sched_ yield 系统 调用 ， 进 程 不 再 处 于 可 执行 状态 。 























:进程 终止 了 。 














-被 一 个 优先 级 更 高 的 进程 抢占 。 
































如 果 FIFO 类 型 的 进程 通过 sched_yield 系 统 调 用 主动 让 出 了 CPU， 那 么 内 核 会 将 该 进程 放 到 对 应 队列 的 尾部 ， 如 果 进 程 
被 更 高 优先 级 的 进程 抢占 ， 那 么 该 进程 在 队列 中 的 位 置 不 变 ， 一 旦 高 优先 级 的 进程 停止 执行 ， 被 抢占 的 FIFO 类 型 的 进程 会 
继续 执行 。 







































































2.SCHED RR 策略 





在 时 间 片 轮转 的 策略 中 ， 具 有 相同 优先 级 的 进程 轮流 执行 ， 进 程 每 次 使 用 CPU 的 时 间 为 一 个 固定 长 度 的 时 间 片 。 使 用 
SCHED_RR 策 略 的 实施 进程 一 旦 被 调度 器 选中 ， 就 会 一 直 占 有 CPU 资 源 ， 直 到 下 面 的 某 种 情况 发 生 : 







































































* 时 间 片 耗 尽 。 








进程 自动 放弃 CPU: 或 者 执行 了 阻塞 式 的 系统 调用 ， 或 者 主动 执行 sched_yield 函 数 让 出 CPU 资源 。 


进程 终止 了 。 














被 更 高 优先 级 的 进程 抢占 。 















































前 两 种 情况 下 ，SCHED _RR 策 略 的 进程 会 被 放 到 其 优先 级 运行 队列 的 队 尾 。 最 后 一 种 情况 下 ， 被 抢占 的 SCHED_RR 策 
略 的 实施 进程 仍然 位 于 其 运行 队列 的 头 部 ， 在 更 高 优先 级 的 进程 运行 结束 后 ， 被 抢占 的 进程 会 继续 执行 ， 直 到 其 时 间 方 的 
剩余 部 分 耗 光 为 止 。 
































在 时 间 片 轮转 策略 中 ， 时 间 片 的 长 度 是 一 个 关键 的 参数 。POSIX 定 义 了 接口 来 查询 SCHED_RR 策 略 的 时 间 片 长 度 : 


#include <sched.h> 
int sched rr get interval (pid t pid, struct timespec * tp) 














默认 情况 下 ，SCHED_RR 类 型 进程 的 时 间 片 总 是 100 毫 秒 。 如 果 内 核 版 本 不 低 于 3.9， 时 间 片 的 大 小 可 以 通过 调 

















整 /proc/sys/kernel/sched rr_ timeslice ms 的 值 来 调整 I 












































伴随 着 时 钟 中 断 处 理 程序 ，scheduler tick 函 数 会 根据 当前 进程 的 调度 类 执行 对 应 的 task tick 函 数 ， 如 下 所 示 ; 











curr->sched class->task tick(rq, curr, 0); 








实时 调度 类 的 task tick 函 数 为 task tick rt， 该 函数 的 实现 代码 如 下 所 示 : 





static void task tick rt(struct rq *rqg, struct task struct*p, int queued) 
{ 

update curr rt (rq); 

watchdog (rgq, p); 

/*FIFO 类 型 没有 时 间 片 的 概念 ， 不 会 因为 执行 时 间 足 够 长 而 被 抢占 


if (p->policy != SCHED RR) 
return; 
/* 如 果 时 间 片 还 没 到 ， 就 直接 返回 


if (--p->rt.time slice) 
return; /* 时 间 片 已 经 耗 尽 ， 先 将 进程 的 时 间 片 重新 初始 化 为 默认 时 间 片 





p->rt.time slice = DEF TIMESLICE; 
/* 如 果 队列 上 存在 其 他 进程 ， 则 将 自身 移 到 队列 的 尾部 ， 











* 并 且 设置 


need_ resched 标 志 位 


if (p->rt,.run list.prev != p->rt.run list,.next) { 
requeue task rtl(rq, p, 0); 
set tsk need resched (p); 

} 



































从 上 面 的 代码 不 难看 出 ， 采 用 SCHED_RR 调 度 策略 的 实时 进程 ， 时 间 片 大 小 为 时 钟 滴答 的 整数 倍 。 如 果 系 统 
CONFIG_HZ 为 230， 那 么 每 4 毫秒 一 个 时 钟 滴答 ， 即 时 间 片 大 小 总 是 4 毫秒 的 整数 倍 。 


























现在 的 服务 器 上 一 般 不 止 一 个 CPU， 在 多 CPU 系统 上 实时 进程 的 负载 均衡 是 需要 解决 的 问题 。 严 格 来 讲 ， 对 于 具有 N 
个 CPU 的 系统 ，N 个 最 高 优先 级 的 可 运行 状态 的 实时 进程 《如 果 存 在 大 于 等 于 N 个 实时 进程 的 话 ) 应 该 占据 N 个 CPU 核 。 对 
实时 进程 负载 均衡 这 个 话题 感 兴趣 的 话 ， 可 以 阅读 《Process Scheduling in Linux》 D 这 篇 文献 ， 限 于 篇 幅 ， 此 话题 不 再 展 
开 论述 。 
























































3.SCHED OTHER 策略 








SCHED_ OTHER 策略 不 属于 实时 调度 的 范畴 。SCHED_ OTHER 和 下 面 要 讨论 的 SCHED BATCH、SCHED IDLE 策 略 同 
属于 完全 公平 调度 的 范畴 。 事 实 上 ， 我 们 遇 到 的 大 多 数 进程 都 是 属于 SCHED_OTHER 的 调度 策略 。 















































前 面 讨 论 的 是 nice 值 在 -20~19 范 围 内 的 进程 ， 都 是 属于 SCHED OTHER 的 调度 策略 。 在 这 种 调度 策略 下 ， 不 同 的 nice 
值 ， 意 味 着 不 同 的 时 间 片 权重 。 优 先 级 越 高 的 普通 进程 ， 将 获得 越 多 的 CPU 时 间 。 






































4.SCHED BATCH 策 略 











尽管 可 以 通过 POSIX 实 时 调度 的 API 设 置 进程 的 策略 为 SCHED BATCH， 但 是 SCHED BATCH 策 略 并 不 属于 实时 调 








六 





























SCHED_BATCH 策 略 是 在 Linux 2.6.16 的 内 核 中 加 入 的 。 最 初 引入 这 个 策略 的 目的 是 告知 内 核 ， 指 定 这 个 策略 的 进程 并 
非 交互 型 的 进程 ， 不 需要 根据 休眠 时 间 更 改 优 先 级 。 









































这 个 策略 主要 用 于 早期 的 O (1) 调度 器 ， 对 于 完全 公平 的 

















样 。 





5.SCHED IDLE 策 略 








调度 ，SCHED_BATCH 策 略 和 SCHED_ OTHER 策略 几乎 一 














SCHED IDLE 策 略 也 隶属 于 完全 公平 调度 的 范畴 。 采 取 SCHED IDLE 调 度 策略 的 进程 拥有 非常 低 的 优先 级 ， 比 nice 值 
为 19 的 进程 的 优先 级 还 要 低 (nice 值 是 19 的 进程 ， 其 权重 是 15， 采 用 SCHED IDLE 调 度 策 略 的 进程 其 权重 是 3) 。 一 般 来 
说 ， 该 策略 用 于 运行 优先 级 非常 低 的 进程 ， 通 常 在 系统 中 没有 其 他 任务 需要 使 用 CPU 时 这 些 任 务 才 会 运行 。 





























































































































完全 公平 调度 类 中 负责 检查 是 否 应 该 唤醒 抢占 的 check preempt wakeup 函 数 中 有 如 下 的 语句 : 











if (unlikely (curr->policy == SCHED IDLE) && 


likely (p->policy != SCHED IDLE)) 
goto preempt; 






































这 段 代码 表明 ， 在 CFS 调 度 域 内 ， 如 果 醒 来 的 候选 进程 采 月 
策略 是 SCHED IDLE， 那 么 抢占 总 是 会 发 生 。 











[1] http://kernelnewbies.org/Linux 3.9。 


上 的 不 是 SCHED _IDLE 策 略 ， 而 当前 运行 的 进程 采用 的 调度 











[2] https://criticalblue.con/news/wp-content/uploads/2013/12/linux _ scheduler notes_final.pdf。 


5$.6.2 ”实时 调度 相关 API 





Linux 下 可 以 通过 sched_setscheduler 函 数 来 修改 进程 的 调度 策略 及 优先 级 ， 其 接口 定义 如 下 : 














#include <sched.h> 
int sched setscheduler (pid t pid, int policy, 

const struct sched param *param); 
struct sched param { 


int sched priority; 






























































该 接口 用 于 修改 pid 对 应 进程 的 调度 策略 和 优先 级 。 当 pid 等 于 0 时 ， 修 改 函 数 调 用 进程 的 调度 策略 和 优先 级 。 策 略 和 优先 级 的 有 效 值 如 表 5-5 
所 示 。 








策 略 描述 sched_param.sched_priority 
SCHED FIFO 实时 进程 ， 先 进 先 出 的 策略 人 
ED RR 实时 进程 ， 时 间 片 轮转 的 策略 1 一 99 
SCHED oTHER 普通 进程 ， 非 实时 进程 的 默认 调度 策略 0 


SCHED BATCH 普通 进程 ， 批 处 理 0 
SCHED IDLE 





比 nice 值 为 19 的 普通 进程 优先 级 还 要 低 0 


sched_setscheduler 函 数 调 用 成 功 时 返回 0， 失 败 时 返回 -1， 并 设置 errno。 
























































设置 进程 调度 策略 和 优先 级 的 方法 如 下 面 的 代码 所 示 。 下 面 的 代码 将 进程 的 调度 策略 设置 成 JSCHED_RR， 并 且 其 优先 级 为 99， 即 实时 进 






































口 已 a 

程 中 的 最 低 优先 级 。 
struct sched param sp = { .sched priority = 99 }; 
ret = sched setscheduler (0, SCHED RR, &sp); 
if (ret == -1) 


{ 
/*error handler*/ 


} 






































通过 fork 创 建 的 子 进程 会 保持 父 进程 的 调度 策略 和 优先 级 。 有 些 时 候 ， 不 希望 子 进程 继承 父 进 程 的 调度 策略 和 优先 级 ， 尤 其 是 父 进 程 是 实时 
进程 或 nice 值 是 负 值 的 时 候 。Linux 自 2.6.32 版 本 开始 ， 提 供 了 SCHED RESET_ ON FORK 选项， 设置 了 该 选项 ， 子 进程 就 不 会 继承 父 进程 的 
几 度 策略 或 nice 值 了。 可 通过 如 下 代码 设置 该 标志 位 : 























































































































i 




















ret = sched setscheduler (0, SCHED RR |SCHED RESET ON FORK, &sp); 























“如 果 调 用 进程 的 调度 策略 是 SCHED_FIFO 或 SCHED_RR， 那 么 将 fork 创 建 出 来 的 子 进程 调度 策略 重 设 成 SCHED_OTHER.。 


















































:如 果 调 用 进程 的 mice 值 是 负 值 ， 那 么 将 fork 创 建 出 来 的 进程 的 mice 值 重新 设置 成 0。 





























如 何 查看 进程 的 调度 策略 及 调度 参数 ? 可 使 用 如 下 语句 : 





int sched getscheduler (pid 七 pid) 
int sched getparam(pid t pid, struct sched param *param); 


























sched_getscheduler 函 数 可 以 返回 进程 的 调度 策略 ， 但 是 无 法 返回 进程 的 调度 参数 。 








int policy = sched getschequler (0) ， 
Switch (policy) 
{case SCHED OTHER: /wy 
case SCHED FIFO: 
A 


case SCHED RR: 
(ee 






































对 于 实时 进程 ， 可 以 调用 sched_getparam 函 数 来 获得 其 优先 级 ， 代 码 如 下 所 示 : 








struct sched param sp: 


int ret 


ret = sched getparam(0,&sp); 
if(ret == -1) 
{/*error handle here*/ 


printf(* 


process priority is %d\n” 


Sp.sched priority); 





























sched setscheduler 函 数 用 来 同时 设置 调度 策略 和 调度 参数 。 除 了 该 接口 外 ，Linux 还 提供 了 一 个 功能 弱化 的 函数 即 sched_setparam， 该 函数 可 
以 用 来 调整 进程 的 调度 参数 ， 定 义 如 下 : 

















#include <sched.h> 
int sched setparam(pid t pid, const struct sched param *param); 





























通过 该 接口 ， 可 以 调整 实时 进程 的 优先 级 ， 使 用 方法 如 下 : 




















struct sched param sp ; 
sp.sched priority = 15; 

ret = sched setparam(0,&sp); 
if(ret == -1) 


} 


/*error handler*/ 





可 以 通过 ps 命令 的 输出 来 查看 进程 的 调度 策略 和 优先 级 : 





manu@manu-rush:~$ ps -p 7110 -o pid,cmd,sched,rtprio,pri 
PID CMD SCH RTPRIO PRI 
7110 sleep 100 2 99 139 





在 sched 字 段 中 SCHED_OTHER、SCHED FIFO、SCHED RR、SCHED_ BATCH 和 SCHED IDLE 对 应 的 值 分 别 为 0(、1、2、3 和 5。 

















除了 ps 命令 外 ，util-linux 包 中 提供 了 chrt 工 具 ， 可 以 查看 和 修改 进程 的 调度 策略 和 优先 级 。 








查看 进程 的 调度 策略 和 优先 级 的 方法 如 下 : 





manu@manu-rush:~$ chrt -p 7125 

pid 7125's current scheduling policy: SCHED RR 
pid 7125's current scheduling priority: 77 
manu@manu-rush:~$ chrt -P 1 

pid 1's current scheduling policy: SCHED OTHER 
pid 1's current scheduling priority: 0 





修改 进程 的 调度 策略 和 优先 级 的 方法 如 下 : 





/*71 35 进 程 最 初 是 普通 进程 ， 调 度 策略 为 


SCHED OTHER*/ 

root@manu-rush:~# chrt -p 7135 

pid 7135's current scheduling policy: SCHED OTHER 
pid 7135's current scheduling priority: 0 

/ *- 工 表示 修改 调度 策略 为 


SCHED_RR， 


40 表 示 修 改 优先 级 为 


40*/ 

root@manu-rush:~# chrt -p -r 40 7135 
root@manu-rush:~# chrt -p 7135 

pid 7135's current scheduling policy: SCHED RR 
pid 7135's current scheduling priority: 40 

/ * 一 王 表 示 修 改 调度 策略 为 


SCHED_FIFO, 


20 表 示 修 改 优先 级 为 


2 

root@manu-rush:~# chrt -p -f 20 7135 
root@manu-rush:~# chrt -p 7135 

pid 7135's current scheduling policy: SCHED FIFO 
pid 7135's current scheduling priority: 20 





5.6.3 ”限制 实时 进程 运行 时 间 





实时 进程 的 优先 级 高 于 普通 进程 ， 如 果实 时 进程 处 于 可 执行 的 状态 ， 那 么 普通 进程 无 法 获得 CPU 
资源 。 如 果 使 用 实时 调度 策略 的 进程 出 现 了 bug， 始 终 处 于 可 运行 的 状态 ， 系 统 将 不 会 调度 其 他 普通 进 
程 。 这 种 情况 是 非常 危险 的 ， 系 统 很 可 能 会 失去 控制 ， 而 用 户 甚至 超级 用 户 也 无 能 为 力 。 























为 了 防止 出 现 这 种 情况 ， 系 统 做 了 改进 ， 纵 然 始终 存在 可 以 运行 的 实时 进程 ， 仍 然 允许 普通 进程 
获得 一 定 的 CPU 时 间 。 























系统 提供 了 控制 选项 来 控制 单位 时 间 内 最 多 分 配 多 少 CPU 时 间 给 实时 进程 。 在 Linux 中 ， 这 两 个 控 





SySsct1 -n kernel.sched rt period us 
1000000 本 四 
Sysctl -n kernel.sched rt runtime us 
950000 





这 两 个 参数 的 含义 是 在 以 sched_rt_period_us 为 一 个 周期 的 时 间 内 ， 所 有 实时 进程 运行 的 时 间 总 和 不 
超过 sched_rt_runtime_ us。 这 两 个 配置 项 的 默认 值 为 1 秒 和 0.95 秒 ， 表 示 每 秒 钟 为 一 个 周期 ， 所 有 实时 进 
程 运行 的 总 时 间 不 超过 0.95 秒 ， 剩 下 的 0.05 秒 留 给 普通 进程 。 有 了 这 个 机 制 ， 哪 怕 始 终 有 实时 进程 处 于 
TASK_ RUNNING 状态 ， 普 通 进 程 也 能 获得 运行 的 机 会 。 




















(全 


如 果 在 一 个 周期 的 时 间 内 ， 实 时 进程 对 CPU 的 需求 不 足 0.95 秒 ， 那 么 剩余 的 时 间 都 会 分 配给 普通 尼 
进程 。 而 如 果实 时 进程 对 CPU 的 需求 大 于 0.95 秒 ， 它 也 只 能 够 运行 0.95 秒 ， 剩 下 的 0.05 秒 留 给 其 他 普通 
进程 。 但 是 如 果 0.05 秒 内 并 没有 任何 普通 进程 处 于 可 运行 状态 ， 实 时 进程 能 否 运行 超过 0.95 秒 吗 ? 答案 
还 是 不 能 ， 内 核 宁 可 让 CPU 闲 着 ， 也 不 给 实时 进程 使 用 。 























但 是 前 面 讨论 的 场景 都 是 单 CPU 的 场景 ， 如 果 存 在 N 个 CPU， 那 么 所 有 CPU 上 的 所 有 实时 进程 占有 
CPU 的 上 限 应 该 为 N*sched rt runtime_us/sched rt period us。 有 的 CPU 上 实时 进程 对 CPU 的 需求 超过 
sched rt runtime us， 而 有 的 CPU 上 实时 进程 对 CPU 的 需求 不 足 sched rt runtime us， 因 此 内 核 允 许 CPU 
之 间 互 相 拆 借 。 若 实时 进程 在 CPU 上 占用 的 时 间 超过 了 sched_rt_runtime_us， 则 该 实时 进程 会 尝试 去 其 
他 CPU 上 借 时 间 ， 将 其 他 CPU 剩余 的 时 间 借 过 来 。 这 样 做 的 好 处 是 避免 了 进程 在 CPU 之 间 迁 移 导 致 的 上 
下 文 切 换 、 组 存 失效 等 开销 。 这 部 分 逻辑 出 现在 kernel/sched rtc 中 的 sched rt runtime_exceeded 函 数 ， 该 


函数 会 通过 balance _ runtime 函数 向 其 他 CPU 借用 时 间 [1]。 


























事实 上 ， 实 时 进程 也 支持 组 调度 ， 可 以 控制 一 组 实时 进程 (task_group) 占用 的 CPU 时 间 ， 将 CPU 
占用 的 管理 分 配 得 更 加 细致 D] 。 























[1] Linux 进 程 组 调度 机 制 分 析 : http://www.oenhan.com/task-group-sched#toc-4。 
[2] Linux 组 调度 浅 析 : http://kouucocu.lofter.com/post/l1cdb8c4b 50f6314。 


S$.7 CPU 的 亲和力 





























在 对 称 多 处 理 器 (SMP) 环境 中 ， 一 个 进程 被 重新 调度 时 ， 不 一 定 是 在 上 次 执行 的 CPU 上 运行 。 















































同一 个 进程 在 不 同 CPU 之 间 迁 移 会 带 来 性 能 的 损失 ， 损 失 的 主要 原因 在 于 缓存 。 在 进程 迁移 到 新 的 处 理 器 上 后 写 入 新 数据 到 内 存 
时 ， 原 有 处 理 器 的 缓存 就 过 期 了 。 当 进程 在 不 同 处 理 器 之 间 迁 移 时 ， 会 带 来 两 方面 的 性 能 损失 ， 
























































进程 不 能 访问 老 的 缓存 数据 ; 














' 原 处 理 器 中 缓存 中 的 数据 必须 标记 为 无 效 。 

















由 于 迁移 会 带 来 性 能 损失 ， 因 此 进程 调度 器 趋 于 把 进程 固定 在 一 个 处 理 器 上 执行 。 












































如 何 查 看 进程 当前 运行 在 哪个 CPU 上 ? 可 以 通过 ps 命令 的 PSR 字 段 来 查看 进程 当前 执行 或 上 一 次 执行 时 所 在 的 CPU 编号 。 因 为 进程 
调度 并 不 保证 进程 总 是 固定 在 某 个 CPU 上 ， 所 以 多 次 查看 进程 的 PSR， 其 值 可 能 会 发 生变 化 。 
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root@manu-rush:~# Ps -p 7214 -o pid,cmd,psr 
PID CMD PSR 
7214 sleep 1000 0 




















有 时 候 需 要 把 进程 绑 定 到 某 个 或 某 几 个 CPU 上 运行 。 这 就 需要 设置 进程 的 CPU 硬 亲 和 力 了 。Linux 提 供 了 非 标准 的 系统 调用 来 获取 和 
修改 进程 的 硬 灯 和 力 : 即 sched_setaffinity 函 数 和 sched_getaffinity 函 数 。 


































































































sched_setaffinity 函 数 用 来 设置 pid 指 定 进 程 的 CPU 亲和力 ， 如 果 pid 的 值 为 0， 那 么 该 函数 用 来 修改 调用 进程 的 CPU 亲和力 。 函 数 接口 
定义 如 下 : 









































#define GNU SOURCE 

#include <sched.h> 

int sched setaffinity(pid t pid, size t cpusetsize, 
和 pu_set 七 *mas 








cpu_set t 数 据 结构 是 位 掩 码 ， 但 是 不 应 该 直接 操作 cpu_set t 类 型 的 变量 。Linux 提 供 了 一 组 宏 来 操作 cpu_set t 类 型 的 变量 : 














/* 将 
Set 初始 化 为 空 


Sy 
void CPU ZERO(cpu set t *set); 
/* 将 


CPU 指定 的 
CPU 添加 到 
Set 中 


大 


站 
void CPU _ SET (int cpu, cpu set t *set); 


Set 中 删除 


CPU cpu*/ 
void CPU CLR(int cpu, cpu set t *set); 
/* 判 断 


CPU cpu 是 否 


Set 中 的 成 员 


wy 
int CRU ISSET RE CPU ep set t *spt)? 





























ey 

















CPU 和 集合 中 的 编号 从 0 开始 。 一 般 在 调用 CPU_XXX 系 列 函 数 之 前 ， 需 要 对 系统 中 的 CPU 核 数 了 然 于 胸 ， 才 能 有 的 放 矢 。 指 定 cpu 的 值 
比 系统 中 的 最 大 CPU 编号 还 大 是 没有 意义 的 。nproc 命 令 和 1lscpu 命 令 都 可 以 获取 系统 的 CPU 核 数 ， 代 码 如 下 : 











Ea 




















manu@manu-rush:~$ nproc 


manu@manu-rush:~$ lscpu 


Architecture: x86 64 

CPU op-mode(s): 32-bit, 64-bit 
Byte Order: Little Endian 
US 


On-line CPU(s) list: Or1 








通过 proc 文 件 系统 的 /proc/cpuinfo 也 可 以 获取 CPU 的 核 数 。 




















可 以 通过 下 面 的 代码 将 某 进 程 迁移 到 CPU 1 上 : 























Chu Set t Bets 
/* 必 须 首先 调用 


CPU_ZERO 清 空 ， 不 可 想当然 地 认为 是 空 


wy 

CPU ZERO (&set); 

CPU_SET(1, &set); 

sched setaffinity (pid,sizeof (cpu set t),&set); 

















Linux 提 供 了 sched_sgetaffinity 接 口 来 查看 进程 的 CPU 亲和力 : 

















cpu set t sets 
/* 必 须 首先 调用 


CPU _2PERO 清 空 ， 不 可 想当然 地 认为 是 空 


nt 

CPU_ ZERO (&set); 

CPU_SET(1, &set); 

sched setaffinity (pid,sizeof (cpu set t),&set); 





















































调用 sched_getaffinity 之 前 ， 需 要 先 调用 CPU_ZERO 将 set 清 空 。 函 数 调 
哪些 CPU 在 集合 中 ， 而 是 应 该 用 CPU_ISSET 来 判断 。 








成 功 时 ， 会 将 结果 记录 在 set 中 ， 但 是 不 要 直接 操作 set 来 判断 












































内 核 如 何 保证 进程 只 会 在 某 些 CPU 上 执行 ? 内 核 中 的 进程 对 应 的 进程 描述 符 中 有 个 cpumask_t 类 型 的 成 员 变 量 cpus_allowed， 该 成 员 
变量 会 记 住 进程 允许 的 CPU。 内 核 在 调度 的 时 候 会 通过 select task rq 来 选择 CPU， 只 会 选择 出 允许 的 CPU。 













































































static inline 
int select task rql(struct task struct *p, int sd flags, int wake flags) 
{ 

int cpu = p->sched class->select task rql(lp, sd flags, wake flags); 

if (unlikely(!cpumask test cpul(cpu, tsk cpus allowed(p)) || 

!cpu online (cpu))) 
cpu = select fallback rql(task cpul(p), p); 
return cpu; 


; 









































有 个 很 有 意思 的 话题 是 内 核 调 用 select task rq 的 时 机 : 当 新 的 进程 创建 出 来 时 ， 当 进程 调用 exec 时 ， 当 进程 从 睡眠 中 醒 来 时 ， 都 是 
调用 select task rq 的 好 时 机 《如 图 $-26 所 示 ) ， 可 以 通过 这 些 时 机 来 实现 各 个 CPU 之 间 的 负载 均衡 。 

























































































除了 编程 接口 可 以 获取 和 修改 进程 的 亲和力 以 外 ，Linux 的 util-linux 包 中 还 提供 了 tasket 工 具 以 命令 行 的 方式 做 同样 的 事情 。 它 查询 进 
程 的 CPU 亲和力 的 方法 如 下 : 


























7 








manu@manu-rush:~$ taskset -P 1 
pid 1"s current affinity mask: 3 





阻塞 型 系统 调用 





用 户 层 


内 核 层 


SD BALANCE FORK SD BALANCE EXEC SD BALANCE WAKE 








Slade el Mal 














图 5-26 ”调用 select_task_rq 的 时 机 





进程 1 的 mask 为 3=0x11， 即 允许 在 CPU 0 和 CPU 1 上 运行 。 





修改 进程 的 CPU 亲和力 的 方法 如 下 : 








/ * 人 允许 进程 


700 运 行 在 


CPUO CEUS CEUT CPUS CEUS CPULO CEULLE 


四 
/ 

taskeset =pe O37-11 700 

manu@manu-rush:~$ sudo taskset -pc 1 2000 
pid 2000"'8 current affinity list: 0,1 

pid 2000's new affinity list: 1 



































除了 tasket 工 具 外 ，cpuset 也 可 以 用 来 设 定 CPU 亲 和 力 。cpuset 是 Linux 控 制 组 (control groups) 中 的 一 个 子 系统 ， 该 子 系统 的 用 途 是 管 
理 进程 可 以 使 用 的 CPU 核 心 和 内 存 节 点 。 使 用 cpuset 之 前 ， 首 先 要 确认 内 核 是 否 已 经 提供 了 对 cpuset 功 能 的 支持 : 





















































root@manu-rush:/boot# grep "CONFIG CPUSETS" config-3.13.0-32-generic 
CONFIG CPUSETS=y 














Linux 将 cgroups 实 现成 了 文件 系统 。 在 较 新 的 Linux 发 行 版 本 中 (如 Ubuntu 14.04) ， 系 统 已 经 挂 载 了 所 有 的 cgroup 子 系统 ， 通 过 mount- 
tcgroup 命 令 来 查看 。 如 果 操 作 系 统 并 没有 挂 载 cpuset 子 系统 ， 那 么 可 以 通过 如 下 命令 手工 挂 载 : 
































' 














mkdir /dev/cpuset 
mount -t cgroup -Oo cpuset none /dev/cpuset 























执行 完 挂 载 后 ， 通 过 mount 命 令 可 以 看 到 一 个 新 的 cpuset 类 型 的 文件 系统 挂 载 到 了 /dev/cpuset 目 录 下 : 








none on /dev/cpuset type cgroup (rw,cpuset) 






































全 


我 们 可 以 创建 一 个 新 的 CPU 分 配 组 ， 比 如 GroupA， 方 法 很 简单 ， 就 是 在 /cgroup 下 创建 录 ， 方 法 如 下 : 














mkdir /dev/cpuset/GroupA 























在 cpuset 中 设置 了 新 的 群 组 之 后 ， 该 群 组 的 目录 下 有 很 多 的 文件 ， 对 应 不 同 的 配置 项 ， 如 图 $-27 所 示 。 大 部 分 配置 项 都 是 可 选 的 ， 
但 cpusetcpus 和 cpusetmems 这 两 项 分 别 用 来 指定 群 组 允许 使 用 的 CPU 核心 和 内 存 节 点 ， 是 强制 配置 项 ， 必 须要 指定 。 














rootGmanu-rush:/dev/VcpusetVGroupA# 1LL 


total 


drwxr- 
drwxr- 
-TW-Tr- 


9 


XT-X 


XT-X 
sl We 


--W--W--W- 
-rw-r--r-- 
-rw-r--r-- 
-rw-r--r-- 


-TW-T- 
-TW-T- 


Ey -~ 


-rw-r--r-- 
-Tr--r--r-- 
-rw-r--r-- 
-rw-r--r-- 


-rw-Tr- 
-TW-T- 


-= 六- - 


2 
3 
1 
1 

1 

1 

1 
-Tr-- 1 
1 

1 

1 

1 

1 

可 
-Tr-- 1 
1 


-TW-T--r-- 
i el i et 
-rw-r--r-- ] 
rootGmanu- rush:/dev/cpuset/VGroupA## | 





root 
root 
root 
root 
root 
root 
root 
root 
root 
root 
root 
root 
root 
root 
root 
root 
root 
root 


root 
root 
root 
root 
root 
root 
root 
root 
root 
root 
root 
root 
root 
root 
root 
root 
root 
root 

















Jan 
Jan 
Jan 
Jan 
Jan 
Jan 
Jan 
Jan 
Jan 
Jan 
Jan 
Jan 
Jan 
Jan 
Jan 
Jan 
Jan 
Jan 


OOOOOOOOOOOODOOODOOOOO 


24 
24 
24 
24 
24 
24 
24 
24 
24 
24 
24 
24 
24 
24 
24 
24 
24 
24 


fb 
7 
3 
3 
23: 
re 
ee 
2 
233 
23: 
Ps 
Pe 
Sy 


23 


23 : 
FF 后 全 
23 : 
23< 
23 : 


Le 


54 。 


55 
55 
35 
55 
55 
5 
55 
55 
3 
55 


55 
55 
55 
55 
3 


yh 

ef 
cgroup 
cgroup 
cgroup 
cpuset 


cpuset. 


cpuset 
cpuset 
cpuset 
cpuset 
cpuset 
cpuset 
cpuset 


cpuset. 


cpuset 


notify_ 


tasks 


.Clone children 
.event control 


.procs 


.Chu exclusive 


cpus 


.mem exclusive 


.mem hardwall 


.memory migrate 
.memory_ pressure 
.memory spread page 
-memory spread slab 


.mems 


sched _ Load balance 


.Sched relax domain_ Level 


on_ release 


图 5-27 ”cpuset 子 系统 下 task group 的 配置 文件 





















































下 面 我 们 通过 如 下 语句 将 GroupA 中 所 有 的 进程 限制 在 CPU 1 上 : 
echo "1" > /dev/cpuset/GroupA/cpuset.cpus 
echo "0" > /dev/cpuset/GroupA/cpuset .mems 
设置 好 GroupA 人 允许 使 用 的 CPU 后 ， 就 可 以 将 某 些 进程 放 入 GroupA 中 了 ， 按 照 设 定 ， 这 些 进程 只 会 使 用 CPU 1。 比 如 将 shell 本 身 的 PID 


归于 GroupA， 这 样 在 该 shell 上 启动 的 所 








= 

















jr 








程 都 会 归于 这 个 GroupA 下 : 





echo $$ > /dev/cpuset/GroupA/tasks 





下 加 





[图 





5-28 所 示 。 


manu@manu- rush:~$ 


PID 
3795 
3796 


3797 
3798 
3799 
manu@manu-rush:~$ 力 


PSR CMD 


stress 
stress 
stress 
stress 


Stress 





-C stress -0 pid,psr,cmd,etime,cgroup,%cpu 
ELAPSED CGROUP 


图 5-28 

















Sh 2 


01:25 
01:25 
01:25 
01:25 











cpuset: 
:Cpuset : 
:Cpuset : 
:Cpuset : 
:Cpuset : 


/GroupA 
/GroupA 
/GroupA 
/GroupA 
PAC 





通过 cpuset 绑 定 到 CPU 1 上 运行 的 进程 ps 的 输 昌 





LL 


在 该 shell 上 通过 stress-c 4 命令 ， 启 动 4 个 进程 执行 死 循 环 ， 消 耗 大 量 的 CPU 资 源 ， 通 过 ps 命令 可 以 看 到 ， 这 4 个 进程 总 是 运行 在 CPU 1 




















悍 号 是 一 种 软件 中 断 ， 用 来 处 理 异 步 事 件 。 内 核 递 送 这 些 异 步 事件 到 某 个 进程 ， 告 诉 进程 某 个 特 
殊 事 件 发 生 了 。 这 些 异步 事件 ， 可 能 来 自 硬 件 ， 比 如 访问 了 非法 的 内 存 地 址 ， 或 者 除 以 90 了; 可 能 来 自 
用 户 的 输入 ， 比 如 shell 终 端 上 用 户 在 键盘 上 敲 击 了 Ctrlt+C; 还 可 能 来 自 另 一 个 进程 ， 甚 至 有 些 来 自 进程 
自身 。 























信号 的 本 质 是 一 种 进程 间 的 通信 ， 一 个 进程 向 为 一 个 进程 发 送信 号 ， 内 核 至 少 传递 了 信号 值 这 个 
字段 。 实 际 上 ， 通 信 的 内 容 不 止 是 信号 值 。 








言 号 机 制 是 Unix 家 族 里 一 个 古老 的 通信 机 制 。 传 统 的 信号 机 制 有 一 些 浆 端 ， 更 为 严重 的 是 ， 信 和 号 
处 理 函 数 的 执行 流 和 正常 的 执行 流 同 时 存在 ， 给 编程 带 来 了 很 多 的 麻烦 和 困扰 ， 一 不 小 心 就 可 能 掉 入 
陷阱 。 本 章 将 会 介绍 信号 的 方方面面 ， 包 括 传统 信号 的 浆 端 ，Linux 对 信号 机 制 的 改进 ， 以 及 信号 机 制 
里 面 的 陷阱 ， 希 望 对 读者 能 有 所 帮助 。 























6.1 信号 的 完整 生命 周期 





前 文 提 到 过 ， 信 和 号 的 本 质 是 一 种 进程 间 的 通信 。 进 程 之 间 约 定好 : 如 果 发 生 了 某 件 事情 
T (trigger) ， 就 问 目 标 进 程 (destination process) 发 送 某 特定 信号 X， 而 目标 进程 看 到 X， 束 意识 到 T 事 
件 发 生 了 ， 目 标 进程 就 会 执行 相应 的 动作 A (action〉。 











接 下 来 以 配置 文件 改变 为 例 ， 来 描述 整个 过 程 。 很 多 应 用 都 有 配置 文件 ， 如 果 配 置 文件 发 生 改 
变 ， 需 要 通知 进程 重新 加 载 配置 。 一 般 而 言 ， 程 序 会 默认 采用 SIGHUP 信 号 来 通知 目标 进程 重新 加 载 配 
置 文件 。 


























目标 进程 首先 约定 ， 只 要 收 到 SIGHUP， 就 执行 重新 加 载 配置 文件 的 动作 。 这 个 行为 称 为 信号 的 安 
装 〈installation) ， 或 者 信号 处 理 函 数 的 注册 。 安 装 好 了 之 后 ， 因 为 信号 是 异步 事件 ， 不 知道 何 时 会 发 
生 ， 所 以 目标 进程 依然 正常 地 干 自己 的 事情 。 茶 年 茶 月 的 茶 一 天 ， 管 理 员 突然 改变 了 配置 文件 ， 想 通 
知 这 个 目标 进程 ， 于 是 就 向 目标 进程 发 送 了 信号 。 他 可 能 在 终端 执行 了 kill-SIGHUP 命 令 ， 也 可 能 调用 
了 C 的 API， 不 管 怎样 ， 信 号 产生 了 。 这 时 候 ，Linux 内 核 收 到 了 产生 的 信号 ， 然 后 就 在 目标 进程 的 进程 
描述 符 里 记录 了 一 笔 : 收 到 信号 SIGHUP 一 枚 。Linux 内 核 会 在 适当 的 时 机 ， 将 信号 递送 〈deliver) 给 进 
程 。 在 内 核 收 到 信号 ， 但 是 还 没有 递送 给 目标 进程 的 这 一 段 时 间 里 ， 信 和 号 处 于 挂 起 状态 ， 被 称 为 挂 起 
Cpending) 信号 ， 也 称 为 未 决 信号 。 内 核 将 信号 递送 给 进程 ， 进 程 就 会 暂停 当前 的 控制 流 ， 转 而 去 执 
行 信号 处 理 函 数 。 这 就 是 一 个 信号 的 完整 生命 周期 。 































































































一 个 典型 的 信号 会 按照 上 面 所 述 的 流程 来 处 理 ， 但 是 实际 情况 要 复杂 得 多 ， 还 有 很 多 场景 需要 考 
虑 ， 比如 ; 














.目标 进程 正在 执行 关键 代码 ， 不 能 被 信号 中 断 ， 需 要 阻塞 某 些 信号 ， 那 么 在 这 期 间 ， 信 号 就 不 允 
许 被 递送 到 进程 ， 直 到 目标 进程 解除 阻塞 。 











内 核发 现 同一 个 信号 已 经 存在 ， 那 么 它 该 如 何 处 理 这 种 重复 的 信号 ， 排 队 还 是 丢弃 ? 





内核 递送 信号 的 时 候 ， 发 现 已 有 多 个 不 同 的 信号 被 挂 起 ， 那 它 应 该 优先 递送 哪个 信号 ? 








:对 于 多 线程 的 进程 ， 如 果 向 该 进程 发 送信 号 ， 应 该 由 哪个 线程 来 负责 响应 ? 





这 些 问 题 ， 在 接 下 来 的 章节 中 会 逐一 得 到 解决 。 


6.2 ”信号 的 产生 


作为 进程 间 通 信 的 一 种 手段 ， 进 程 之 间 可 以 互相 发 送信 号 ， 然 而 发 给 进程 的 信号 ， 通 常 源 于 内 
核 ， 包 括 : 





硬件 异常 。 


终端 相关 的 信号。 


软件 事件 相关 的 信号。 


6.2.1 硬件 异常 
































硬件 检测 到 了 错误 并 通知 内 核 ， 由 内 核发 送 相应 的 信号 给 相关 进程 。 和 硬件 异常 相关 的 信号 见 表 6-1。 





























[—| 


信 号 
SIGBUS 
SIGEPE 
SIGILL 
SIGSEGV 


常见 的 能 触发 SIGBUS 信 号 的 场景 有 : 


-变量 地 址 未 对 齐 : 很 
会 触发 SIGBUS 信 和 号 。 














表 6-1 与 硬件 异常 有 关 的 信号 


有 让 有 亲朋 


9 进程 尝试 执行 非法 的 机 器 语言 指令 


段 错误 ， 表 示 应 用 程序 访问 了 无 效 地 址 























此 架构 要 求 int 变 量 的 地 址 必须 为 4 字 节 对 齐 ， 否 则 就 











By 












































多 架构 访问 数据 时 有 对 齐 的 要 求 。 比 如 int 型 变量 占用 4 个 字 节 ， 

















有 mmap 将 文件 映射 和 内存， 如果 文 件 大 小 被 其 他 进程 截 短 ， 那 么 在 访问 文件 大 小 以 外 的 内 存 时 ， 会 触发 SIGBUS 信 号 。 











-mmap 映 射 文件 ， 使 月 


EE 





由 


SIGILL 的 含义 是 非法 指令 (illegal instruction) 。 


虽然 SIGFPE 的 后 级 FPE 是 浮 点 异常 (Float Point Exception) 的 含义 ， 但 是 该 异常 并 不 限 了 











F 浮 点 运算 ， 常 见 的 算术 运算 错误 也 会 引发 SIGFPE 信 





。 最 常见 的 就 是 “整数 除 以 0 的 例子 。 

















般 表 示 进 程 执行 了 错误 的 机 器 指令 。 下 面 来 看 一 段 示例 代码 : 





typedef void(*FUNC) (void 
int main (void) 


) 7 




















! const static unsigned char insn[4] = { Oxff, Oxff, Oxff, Oxff }; 
FUNC function = (FUNC) insn; 
function(); 
} 
上 述 代码 中 ， 因 为 函数 地 址 不 是 合法 有 效 的 值 ， 所 以 触发 了 SIGILL 错 误 。 发 生 这 种 错误 ， 一 般 是 函数 指针 遭 到 破坏 ， 当 执行 函数 指针 指向 




















FP 编译 出 来 的 可 执行 程序 ， 在 老 的 机 器 上 























的 函数 时 ， 就 会 触发 SIGILL 信 号 。 男 外 也 可 能 是 由 指令 集 的 演进 引起 的 。 比 如 ， 很 多 在 新 的 体系 结构 








可 能 会 无 法 运行 ， 故 而 在 老 机 器 上 运行 时 ， 也 可 能 产生 SIGILL 信 号。 


























序 员 的 置 梦 。 没 经 历 几 个 刻骨 铭 心 的 段 错误 ， 很 难 成 长 为 合格 的 C 程 序 员 。 由 于 C 语 言 可 以 直接 操作 指针 ， 就 像 时 常 行 














SIGSEGV 是 所 有 C 程 











走 在 河 边 的 顽童 很 难 避 免 湿 鞋 一样 ， 程 序 员 很 难 避 免 段 错误 ， 没 有 经 验 的 程序 员 更 是 如 此 。 常 见 的 情况 有 : 





-访问 未 初始 化 的 指针 或 NULL 指 针 指向 的 地 址 。 



































进程 企图 在 用 户 态 访问 内 核 部 分 的 地 址 。 























当然 ， 程 序 员 不 会 直接 去 做 这 种 傻 事 ， 一 般 来 说 是 由 于 





“进程 尝试 去 修改 只 读 的 内 存 地 址 。 























F 程序 的 错误 ， 导 致 原本 存放 的 指针 被 算 改 成 错乱 值 ， 因 而 在 访问 指针 指向 的 变量 




















时 ， 触 发 了 SIGSEGV 信 和 号。 
































让 到了 了 






























































前 面 所 讲 的 这 四 种 硬件 异常 ， 一 般 是 由 程序 自身 引发 的 ， 不 是 由 其 他 进程 发 送 的 信号 引发 的 ， 这 些 异 常 都 比较 致命 ， 以 至 于 进程 无 法 




































































继续 下 去 。 所 以 这 些 信 号 产生 之 后 ， 会 立刻 递送 给 进 





























程 。 默认 情况 下 ， 这 四 种 信号 都 会 使 进程 终止 ， 并 且 产 生 core dump 文 件 以 供 调试 。 对 于 这 


些 信号 ， 进 程 既 不 能 忽略 ， 也 不 能 阻塞 。 





6.2.2 ”终端 相关 的 信和 号 





对 于 Linux 程 序 员 而 言 ， 终 端 操作 是 免不了 的 。 终 端 有 很 多 的 设置 ， 可 以 通过 执行 如 下 指令 来 得 
看 : 





人 万世 Yy “一 辟 


很 重要 的 是 ， 终 端 定义 了 如 下 几 种 信号 生成 字符 : 


:Ctrlt+C: 产生 SIGINT 信 和 号。 





CtrlH: 产生 SIGQUIT 信 和 号 


.Ctrl+Z:， 产生 SIGTSTP 信 号 








键入 这 些 信号 生成 字符 ， 相 当 于 向 前 台 进 程 组 发 送 了 对 应 的 信和 号 














另 一 个 和 终端 关系 比较 密切 的 信号 是 SIGHUP 信 和 号。 很 多 程序 员 都 遇 到 过 这 种 问题 : 使 用 ssh 登 录 到 
远程 的 Linux 服 务 器 ， 执 行 比较 耗 时 的 操作 《如 编译 项 目 代 码 ) ， 却 因为 网 络 不 稳定 ， 或 者 需要 关机 回 
家 ，ssh 连 接 被 断 开 ， 最 终 导致 操作 中 途 被 放弃 而 失败 。 





之 所 以 会 如 此 ， 是 因为 一 个 控制 进程 在 失去 其 终端 之 后 ， 内 核 会 负责 向 其 发 送 一 个 SIGHUP 信 
在 登录 会 话 中 ，shell 通 常 是 终端 的 控制 进程 ， 控 制 进程 收 到 SIGHUP 信 和 号 后 ， 会 引发 如 下 的 连锁 反应 。 



































shell 收 到 SIGHUP 后 会 终止 ， 但 是 在 终止 之 前 ， 会 向 由 shell 创 建 的 前 台 进 程 组 和 后 台 进 程 组 发 送 
SIGHUP 信 号 ， 为 了 防止 处 于 停止 状态 的 任务 接收 不 到 SIGHUP 信 号 ， 通 常会 在 SIGHUP 信 号 之 后 ， 发 送 
SIGCONT 信 和 号， 唤醒 处 于 停止 状态 的 任务 。 前 台 进 程 组 和 后 台 进 程 组 的 进程 收 到 SIGHUP 信 和 号， 默认 的 
行为 是 终止 进程 ， 这 也 是 前 面 提 到 的 耗 时 任务 会 中 途 失 败 的 原因 。 























注意 ， 单 纯 地 将 命令 放 入 后 台 执 行 〈 通 过 & 符 号 ， 如 下 所 示 ) ， 并 不 能 摆脱 被 SIGHUP 信 号 奶 杀 的 








到 
[GE 


command & 











那么 如 何 让 进程 在 后 台 稳 定 地 执行 而 不 受 终端 连接 断 开 的 影响 呢 ? 可 以 采用 如 下 方法 。 


1.nohup 


可 以 使 用 如 下 方式 执行 命令 : 





nohup command 





标准 输入 会 重 定向 到 /dewnull， 标 准 输出 和 标准 错误 会 重 定 向 到 nohup.out， 如 果 无 权限 写 入 当前 目 
录 下 的 nohup.out， 则 会 写 入 home 目 录 下 的 nohup.out。 


2.setsid 


使 用 如 下 方式 执行 命令 : 





setsid command 








这 种 方式 和 nohup 的 原理 不 太一 样 。nohup 仅 仅 是 使 局 动 的 进程 不 再 响应 SIGHUP 信 和 号， 但 是 setsid 则 
完全 不 属于 shell 所 在 的 会 话 了 ， 并 且 其 父 进 程 也 已 经 不 是 shell 而 是 init 进 程 了 。 














manu@manu-hacks:~$ nohup Sleep 200 & 
[1] 11686 
nohup: 忽略 输入 并 把 输出 追加 到 





"nohup .out" 

manu@manu-hacks:~$ ps -o cmd,pid,ppid,pgid,sid,etime 

CMD PID PPID PGID SID ELAPSED 
-bash 11365 11364 11365 11365 03:59 
sleep 200 11686 11365 11686 11365 00:30 
ps -o cmd,pid,ppid,pgid,sid 11750 11365 11750 11365 00:00 
manu@manu-hacks:~$ setsid Sleep 300 & 

L111]: L910 

[1]+ ”已 完成 


setsid sleep 300 
manu@manu-hacks:~$ ps -p 11912 -o cmd,pid,ppid,pgid,sid,etime 





CMD PID PPID PGID SID ELAPSED 
sleep 300 11912 1 11912 11912 00:48 
3.disown 


很 多 情况 下 ， 启 动 命 令 时 ， 忘 记 了 使 用 nohup 或 setsid， 可 还 有 办 法 亡羊补牢 ? 


答案 是 使 用 作业 控制 里 面 的 disown， 方 法 如 下 : 





manu@manu-hacks:~$ Sleep 1004 & 
[1] 13861 

manuemanu-hacks:~$ jobs -1 

[1]+ 13861 运行 中 





sleep 1004 & 
manu@manu-hacks:~$ disown %1 
manuemanu-hacks:~$ jobs - 


1 
manulmanu-hacks:~$ exit 





使 用 disown 之 后 ，shell 退 出 时 ， 就 不 会 向 这 些 进程 发 送 SIGHUP 信 号 了 。 在 男 一 个 终端 上 ， 仍 然 可 





以 看 到 sleep 1004 在 运行 : 


manu@manu-hacks:~$ ps -eflgrep sleep 


manu 13861 1 0 12:42 00:00:00 sleep 1004 


FA 


当然 ， 还 有 其 他 的 方法 可 以 做 到 这 点 ， 如 screen 命 名 。 对 这 个 感 兴趣 的 朋友 可 以 阅读 网 上 的 参考 资 





也 





料 口 。 








[1] ” Linux 技巧 :让 进程 在 后 台 可 靠 执 行 的 几 种 方法 ，https://www.ibm.com/developerworks/cn/linux/1-cn- 





nohup/。 


6.2.3 ”软件 事件 相关 的 信号 





软件 事件 触发 信号 产生 的 情况 也 比较 多 : 














: 子 进 程 退 出 ， 内 核 可 能 会 向 父 进程 发 送 SIGCHLD 信 和 号 。 



































， 内 核 可 能 会 给 子 进程 发 送信 号 。 


高 
性 
压 

















:定时 器 到 期 ， 给 进程 发 送信 号 。 




















TT 
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我 们 已 熟知 子 进程 退出 时 会 向 父 进程 发 送 SIGCHLD 信 号 。 这 点 在 第 4 章 








已 经 做 了 很 详细 的 分 析 。 





















































与 子 进程 退出 向 父 进程 发 送信 号 相反 ， 有 时 候 ， 进 程 希望 父 进 程 退出 时 向 自己 发 送信 号 ， 从 而 可 以 得 知 父 进程 的 退出 事件 。Linux 也 提供 了 
这 种 机 制 。 









































每 一 个 进程 的 进程 描述 符 task_struct 中 都 存在 如 下 成 员 变量 : 








int pdeath signal; /* The signal sent when the parent dies */ 















































如 果 父 进程 退出 ， 子 进程 希望 收 到 通知 ， 那 么 子 进程 可 以 通过 执行 如 下 代码 来 做 到 : 























Prct1 (PR _SET PDEATHSIG, sig); 



























































父 进 程 退出 时 ， 会 遍历 其 子 进程 ， 发 现 有 子 进程 很 关心 自己 的 退出 ， 就 会 向 该 子 进程 发 送 子 进程 希望 收 到 的 信号 。 





很 多 定时 器 相关 的 函数 ， 背 后 都 滨 扯 到 信号 ， 有 具体 见 表 6-2。 





表 6-2 ”定时 器 相关 的 信和 号 


函 数 相关 信号 
alarm SIGALRM (14) 
ualarm SIGALRM (14) 
setitimer: ITIMER REAL SIGALRM (14) 
setitimer: ITIMER VIRTUAL SIGVTALRM (26) 
setitimer: ITIMER PROF SIGPROF (27) 


timer create 可 以 由 用 户 来 指定 


0.3 


言 号 的 默认 处 理 函 数 




















从 上 








节 可 以 看 出 ， 






































很 多 信号 尤其 





是 传统 的 信号 ， 


都 会 有 默认 的 信号 处 


言 号 的 默认 操作 有 以 下 几 种 ; 


: 显 式 地 忽略 信号 : 即 内 核 将 会 丢弃 


终止 进程 :很 多 信号 








“生成 核心 转 储 文件 

















目标 进程 产生 任何 影响 。 














信号 不 会 对 





该 信号 ， 

















的 默认 处 理 是 终止 进程 ， 即 将 进程 杀 死 。 





























并 终止 进程 : 进程 被 杀 死 ， 






































文件 


来 调试 ， 分 析 进 程 死亡 的 原因 。 























信号 产生 的 源头 有 很 多 。 那 么 内 核 将 信号 递送 给 进程 后 ， 进 程 会 


理 方式 。 如 果 我 们 不 改变 信号 的 处 理 函 数 ， 那 么 收 到 信和 号 之 


执行 什么 操作 呢 ? 


后 ， 就 会 执行 默认 的 操作 。 









































且 产 生 核心 转 储 文件 。 核 心 转 储 文件 记录 了 进程 死亡 现场 的 信息 。 用 户 可 以 使 用 核心 转 储 
止 进程 仅仅 是 使 进程 暂停 ， 将 进程 的 状态 设置 成 























进程 已 经 死亡 ， 但 是 停 























:停止 进程 : 停止 进程 不 同 于 终止 进程 ， 终 止 进程 是 
TASK _STOPPED， 一 旦 收 到 亿 


:恢复 进程 的 执行 ， 和 停 





这 5 种 行为 的 简 重 

















以 继续 执行 。 





次 复 执 行 的 信号 ， 进 程 还 可 














某 些 信号 可 以 使 进程 恢复 执行 。 


上 进程 相对 应 ， 





单 标记 如 下 : 





'ignore 


'terminate 


“core 


“stop 


“continue 





山中 


信 号 
SIGCHLD 
SIGURG 
SIGWINCH 


有 实 上 ， 根 据 信 














体 见 表 6-3 到 表 6-7。 


号 的 默认 操作 ， 可 以 将 传统 信号 分 成 5 派 ， 





表 6-3 ”ignore 派 的 信号 
说 
了 进程 终止 、 


[eS] -一 一 


表 6-4 ”terminate 派 的 信号 


停止 
套 接 字 上 的 紧急 数据 
终端 窗口 大 小 发 生变 化 


明 
止 或 恢复 执行 


信 号 | 什 说 有 明 




















SIGHUP 1 挂 起 (hangup)， 多 用 于 终端 断 开 
SIGINT 2 终端 中 断 
ee | 、 季 死 进香 ， 访 信号 不 能 名 咯 ， 不 能 被 六 ， 用 户 不 能 将 信号 处 理 天 改写 成 用 户 定 
SIGUSR1 10 用 户 自 定 义 信 号 1 
SIGUSR2 1TZ 用 户 自 定义 信号 2 
SIGPIPE 13 管道 断 开 ， 多 见于 socket 通信 
SIGALRM 14 定时 器 到 期 ， 该 信号 多 用 于 实现 定时 器 
终止 进程 。 因 为 SIGKILL 过 于 残暴 ， 进 程 终 止 时 ， 可 能 需要 先 执行 一 些 操作 来 保存 
SIGTERM 15 | 现场 信息 ， 所 以 合理 地 杀 死 进程 的 方法 是 先 发 送 SIGTERM 信号 ， 稍 等 片刻 ， 再 发 送 


SIGKILL 信和 号 
SIGSTKFLT 16 协 处 理 器 栈 错误 ，Linux 并 未 使 用 该 信号 














SIGVTALRM | 26 虚拟 定时 器 过 期 ，setitimer 函数 的 ITIMER_VIRTUAL 模式 
SIGPROF 27 性 能 分 析 定 时 器 过 期 ，setitimer 函数 的 ITIMER_PROF 模式 
SIGIO 29 IO 时 可 能 发 生 

SIGPWR 30 电量 将 要 耗 尽 























表 6-5 ”core 派 的 系统 调用 











千 号 | 蛋 | 说 明 
SIGQUIT 终端 Ctrlf+\ 可 产生 该 信和 号 
SIGILL 非法 的 指令 
SIGTRAP 跟踪 / 断 点 陷阱 ，gdb/strace 一 类 工具 会 使 用 该 信号 人 9。 这 类 工具 会 拦截 或 修改 
SIGTRAP 信和 号 的 信号 处 理 函 数 
( 续 ) 
信 号 说 _ 明 
SIGABRT 进程 中 止 ， 进 程 调用 abort 师 数 会 向 月 身 发 送 SIGABRT 信和 号， 此 外 如 果 使 用 了 断言 
assert，assert 失败 时 也 会 产生 SIGABRT 信号 
SIGBUS 总 线 错误 
SIGFPE | a | 算术 异常 
SIGSEGV | 是:| 役 错误 ,访问 了 非法 的 地 址 
SIGXCPU 突破 了 对 CPU 时 间 的 限制 
SIGXFSZ 突破 了 对 文件 大 小 的 限制 
SIGSYS 无 效 的 系统 调用 
( 注 : ptrace/SIGTRAP/int3 的 关联 ，http://blog.linux.org.tw/~jserv/archives/2010/08/ptrace_sigtrap.html 。) 





表 6-6 ”stop 派 的 信号 


信 号 | 值 说 有 明 
SIGSTOP | 19 | 确保 进程 会 停止 ， 该 信号 不 能 被 忽略 ， 不 能 将 信号 处 理 函 数 改写 成 用 户 指定 的 函数 


SIGTSTP 20 终端 停止 信号 ， 和 SIGSTOP 功能 类 似 ， 但 是 可 以 被 进程 忽略 ， 可 以 被 捕捉 执行 用 户 
指定 的 信号 处 理 函 数 


也 :人 FZ 2 于 证 级 并 二 > 终端 去 1 让 全 站 wd 
Wi ol 用 于 作业 控制 ， 如 漆 司 台 进 程 组 尝试 对 终端 执行 read 操作 ， 终 端 驱 动 程序 就 会 向 该 进 
程 组 发 送 SIGTTIN 信号 


ee gn 如 果 终 端 启用 了 TOSTOP (如 通过 stty tostop 命令 ) 即 不 允许 后 台 进程 向 终端 写 人 人， 而 
某 一 后 台 进 程 尝 试 写 入 终端 时 ， 终 端 驱动 程序 就 会 各 进程 组 发 送 SIGTTOU 信号 


表 6-7 ”continue 派 的 信号 


信 号 




















号 的 这 些 默 认 行 为 是 非常 有 用 的 。 比 如 停止 行为 和 恢复 执行 。 系 统 可 能 有 一 些 备份 的 工作 ， 这 些 工作 优先 级 并 不 高 ， 但 是 去 





1 消耗 了 大 量 
































的 IO 资源 ， 甚 至 是 CPU 资源 《比如 需要 先 压 缩 再 备份 ) 。 这 样 的 工作 一 般 是 在 夜深人静 ， 业 务 稀少 的 时 候 进 行 的 。 在 业务 比较 繁忙 的 情况 下 ， 





产 
航 





如 果 备 份 工作 还 在 进行 ， 则 可 能 会 影响 到 业务 。 这 时 候 停 止 和 恢复 就 非常 有 用 了 。 在 业务 繁忙 之 前 
在 几乎 没有 什么 业务 的 时 候 ， 通 过 SIGCONT 信 和 号 使 备份 进程 恢复 执行 。 


理 函 数 ， 改 而 执行 用 户 自 定义 的 信号 处 理 函 数 。 为 信号 指定 新 的 信号 处 理 函 数 的 动作 ， 被 称 为 信号 的 安装 。glibc 提 化 





















































， 可 以 通过 SIGSTOP 信 和 号 将 备份 进程 暂停 ， 






























































很 多 信号 产生 核心 转 储 文件 也 是 非常 有 意义 的 。 一 般 而 言 ， 程 序 出 错 才 会 导致 SIGSEGV、SIGBUS、SIGFPE、SIGILL 及 SIGABRT 等 信号 的 


生 。 生 成 的 核心 转 储 文件 保留 了 进程 死亡 的 现场 ， 提 供 了 大 量 的 信息 供 程序 员 调 试 、 分 析 错 误 产 生 的 原因 。 核 心 转 储 文件 的 作用 有 点 类 似 于 
空中 的 黑 盒 子 ， 可 以 帮助 程序 员 还 原 事故 现场 ， 找 到 程序 漏洞 。 













































































很 多 情况 下 ， 默 认 的 信号 处 理 函 数 ， 可 外 

















CC 








不 能 满足 实际 的 需要 ， 这 时 需要 修改 信号 的 信号 处 理 函数 。 信 号 发 生 时 ， 不 执行 默认 的 信号 处 



































t 了 Signal 函数 和 sigaction 函 








数 来 完成 信号 的 安装 。signal 出 现 得 比较 早 ， 接 口 也 比较 简单 ，sigaction 则 提供 了 精确 的 控制 。 





64 信和 号 的 分 类 





在 Linux 的 shell 终 端 ， 执 行 kill-1， 可 以 看 到 所 有 的 信和 号 















































1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL 5) SIGTRAP 
6) SIGABRT 7) SIGBUS 8) SIGFPE 9) SIGKILL 10) SIGUSR1 
11) SIGSEGV 12) SIGUSR2 13) SIGPIPE 14) SIGALRM 15) SIGTERM 
16) SIGSTKFLT 17) SIGCHLD 18) SIGCONT 19) SIGSTOP 20) SIGTSTP 
21) SIGTTIN 22) SIGTTOU 23) SIGURG 24) SIGXCPU 25) SIGXFSZ 
26) SIGVTALRM 27) SIGPROF 28) SIGWINCH 29) SIGIO 30) SIGPWR 
31) SIGSYS 34) SIGRTMIN 35) SIGRTMIN+1 36) SIGRTMIN+2 37) SIGRTMIN+3 
38) SIGRTMIN+4 39) SIGRIMIN+5 40) SIGRTMIN+6 41) SIGRTMIN+7 42) SIGRTMIN+8 
43) SIGRTMIN+9 44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47) SIGRTMIN+13 
48) SIGRTMIN+14 49) SIGRIMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13 52) SIGRTMAX-12 
53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9 56) SIGRTMAX-8 57) SIGRTMAX-7 
58) SIGRTMAX-6 59) SIGRTMAX-5 60) SIGRTMAX-4 61) SIGRTMAX-3 62) SIGRTMAX-2 
63) SIGRTMAX-1 64) SIGRTMAX 
rm 
这 些 信号 可 以 分 成 两 类 
二 一 由 
可 靠 信 和 号 。 
一 /> 
不 可 靠 信 号 。 


音 号 值 在 [1，31] 之 间 的 所 有 信号 ， 都 被 称 为 不 可 靠 信 号 ; 在 [SIGRTMIN，SIGRTMAX] 之 间 的 信 
号 ， 被 称 为 可 靠 信 和 号。 











不 可 靠 信 号 是 从 传统 的 Unix 继 承 而 来 的 。 早 期 Unix 系 统 信 号 的 机 制 并 不 完备 ， 在 实践 过 程 中 暴露 了 
很 多 次 端 ， 因 此 把 这 些 早期 出 现 的 信号 值 在 [1，31] 之 间 的 信号 称 之 为 不 可 靠 信号 。 所 谓 不 可 靠 ， 指 的 
是 发 送 的 信号 ， 内 核 不 一 定 能 递送 给 目标 进程 ， 信 号 可 能 会 丢失 。 

















随 着 时 间 的 流逝 ， 人 们 意识 到 原 有 的 信号 机 制 存在 浆 端 。 但 是 [1，31] 之 间 的 信号 存在 已 入 ， 在 很 
多 应 用 中 被 广泛 使 用 ， 出 于 兼容 性 的 考虑 ， 不 能 改变 这 些 信号 的 行为 模式 ， 所 以 只 能 新 增 信号 。 新 增 
的 信号 就 是 我 们 今天 看 到 的 在 [SIGRTMIN，SIGRTMAX] 范 围 内 的 信号 ， 它 们 被 称 为 可 靠 信号 。 




















CE 
安装 、 用 Kill 函 数 〈 或 者 tkill 函 数 ) 发 送 的 信号 ， 就 是 不 可 靠 信 号 ; 用 sigaction 函 数 安装 、 用 sigqueue 函 
数 发 送 的 信号 ， 就 是 可 靠 信 号 。 这 种 理解 是 错误 的 。 信 和 号 的 可 靠 与 否 ， 完 全 取 诀 于 信号 的 值 ， 而 与 采 
用 哪 种 方式 安装 或 发 送 无 关 。 

































































说 了 这 么 多 ， 不 可 靠 信 号 和 可 靠 信 号 的 根本 差异 到 底 在 哪里 ? 根本 差异 在 于 收 到 信号 后 ， 内 核 有 
不 同 的 处 理 方 式 。 























对 于 不 可 靠 信号 ， 内 核 用 位 图 来 记录 该 信号 是 人 否 处 于 挂 起 状态 。 如 果 收 到 茶 不 可 靠 信号 ， 内 核发 
现 已 经 存在 该 信号 处 于 未 决 状态 ， 就 会 简单 地 丢弃 该 信号 。 因 此 发 送 不 可 靠 信号 ， 信 号 可 能 会 丢失 ， 








即 内 核 递送 给 目标 进程 的 次 数 ， 可 能 小 于 信号 发 送 的 次 数 。 
靠 信号 ， 内 核 会 将 信号 挂 到 相应 的 队列 中 ， 
只 能 说 ,在 





对 于 可 靠 信和 号， 内核 内 部 有 队列 来 维护 ， 如 果 收 到 可 
因此 不 会 丢失 。 严 格 说 来 ， 内 核 也 设 有 上 限 ， 挂 起 信号 的 个 数 也 不 能 无 限制 地 增 大 ， 因 此 








一 定 范围 之 内 ， 可 靠 信 号 不 会 被 天 弃 。 


O 注意 ”如 果 细 心 观察 从 kill-1 列 出 的 信号 ， 可 以 看 出 ， 其 中 少 了 32 号 
个 信号 〈SIGCANCEL 和 SIGSETXID) 被 NPTL 这 个 线程 库 征 用 了 ， 用 来 实现 线程 的 取消 。 从 内 核 层 来 


说 ，32 号 信号 应 该 是 最 小 的 实时 信号 〈SIGRTMIN) ， 但 是 由 于 32 号 和 33 号 被 glibc 内 部 征用 了 ， 所 以 


言 号 和 33 号 信号 。 这 两 


百 祥 





























glibc 将 SIGRTMIN 设 置 成 了 34 号 信号。 


6.5 传统 信号 的 特点 















































前 文 提 到 过 ，signal 是 一 个 古老 的 机 制 ， 早 期 的 信号 在 使 用 过 程 中 ， 暴 露出 了 一 些 弊端 ， 那 么 早期 的 信号 机 制 有 什么 浆 端 ， 表 现 出 了 什么 样 
的 行为 模式 呢 ? 今天 Linux 下 的 glibc 提 供 的 信号 函数 是 否 解决 了 这 些 浆 端 ， 它 又 表现 出 了 什么 样 的 行为 模式 呢 ? 下 面 来 一 探究 竟 。 
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传统 的 signal 机 制 ， 分 为 System V 风 格 和 和 BSD 风格 的 signal。 











ibe 提供 了 signal 函 数 来 注册 用 户 定义 的 信号 处 理 函 数 ， 代 码 如 下 : 





#include <signal.h> 
typedef void (*sighandler t) (int); 
sighandler t signal (int signum, sighandler t handler); 














除 此 以 外 ，Linux 还 提供 了 如 下 两 个 接口 供 我 们 “考古 "， 下 面 来 探查 一 下 signal 机 制 的 演化 : 























#include <signal.h> 

typedef void (*sighandler 七 ) (int); 

sighandler t sysV_signal (Int signum, sighandler t handler); 
sighandler t bsd signal(int signum, sighandler t handler) 





从 接口 上 看 ， 存 在 4 种 signal 函 数 ， 见 表 6-8。 








表 6-8 ”四 种 signal 函 数 


函 数 说 明 


syscall(SYS_signal,signo,func) signal 系统 调用 

signal() glibe 的 signal 困 数 
sysv_signal() System V 风格 的 signal 函数 
bsd_signal() BSD 风格 的 signal 函数 





接 下 来 用 实验 的 方法 ， 测 试 各 种 不 同 的 信号 机 制 表现 出 来 的 行为 模式 ， 帮 助 大 家 体会 传统 信号 的 特点 和 弊端 ， 以 及 学 习 Linux 下 glibc 提 供 的 
signal 函 数 的 行为 特性 : 











#include <stdio.h> 
#include <stdlib.h> 
#include <signal.h> 
#include <string.h> 
#include <errno.h> 
#include <sys/syscall.h> 
#define MSG "OMG , I catch the signal SIGINT\n" 
#define MSG END "OK,finished process signal SIGINT\n" 
int do heavy work() 
{ 

int 开学 

int k; 

srand (time (NULL)); 

for(i=0;i < 100000000;i++) 

{ 

k = rand()%®%1234589; 


return 0; 


} 
void signal handler (int signo) 


write (2,MSG, strlen (MSG)); 
do heavy work(); 
write (2,MSG END, strlen (MSG END)); 


int main() 


char input[1024] = {0}; 
#if defined SYSCALL SIGNAL API 


if(syscall (SYS signal ,SIGINT,signal handler) == -1) 
#elif defined SYSV_ SIGNAL API 加 

if(sysv signal (SIGINT,signal _ handler) == SIGERR) 
#elif defined BSD SIGNAL API 

if (bsd signal (SIGINT,signal handler) == SIGERR) 
#else 

if(signal (SIGINT, signal handler) == SIG ERR) 
#endif 加 


{ 
fprintf (stderr,"signal failed\n"); 
return -1; 
} 
printf("input a string:\n"); 
if(fgets (input, sizeof (input), stdin)== NULL) 
: 
fprintf (stderr, "fgets failed(%s)\n",strerror (errno)); 
return =23 
4 
else 
上 
printf ("you entered:%s",input); 
， 


return 0; 




















斜体 的 地 方 是 这 个 测试 程序 的 核心 ， 这 个 函数 分 别 采 用 了 Linux 操 作 系统 提供 的 signal 系 统 调 用 、System V 风 格 的 sysv_signal、BSD 风 格 的 





bsd_signal， 还 有 glibc 提 供 的 标准 API signal 函 数 。 下 面 来 分 别 体会 它们 之 间 的 不 同 之 处 。 

















gcc -Oo systemcall signal -DSYSCALL SIGNAL API signal comp.c 
gcc -o sysv_signal -DSYSV_SIGNAL API signal comp.c 
gcc -o bsd signal -DBSD SIGNRAL API signal comp.c 


gcc -o glibc signal signal comp.c 














t 











E 成 了 4 种 风格 的 测试 程序 ， 接 下 来 就 可 以 验证 它们 的 特性 了 。 





如 
4 











这 里 分 另 


























jsignal 系 统 调 用 。 详 情 可 

















9 












































对 此 ， 无 法 使 用 syscall 函 数 来 1 





© 注意 ”因为 在 x86_64 位 系统 上 ，glibc 的 头 文件 并 没有 声明 signal 系 统 调用 
以 参阅 bits/syscall.h。 不 得 已 ， 只 能 在 32 位 机 器 上 做 测试 ， 比 较 四 种 函数 语义 上 的 差别 。 后 面 的 输出 都 是 在 32 位 机 器 上 的 输出 ， 希 望 不 会 给 大 家 













































































带 来 困扰 。 








6.5.1 ”信号 的 ONESHOT 特 性 


传统 的 System V 风 格 的 signal， 其 注册 的 信号 处 理 函 数 是 一 次 性 的 ， 信 和 号 递送 给 目标 进程 之 后 ， 信 
号 处 理 函 数 会 变 成 默认 值 SIG_DFL。 





manu@manu-hacks:~/code/c/self/signal$ ./sysV_ signal 
input a string: 
hello 
you entered:hello 
manu@manu-hacks:~/code/c/self/signal$ ./sysv_ signal 
input a string: 
hello“^COMG , I catch the signal SIGINT 
~ 
manu@manu-hacks:~/code/c/self/signal$ 











可 以 看 到 第 一 次 实验 的 时 候 ， 输 入 一 个 字符 串 ， 襄 击 回 车 ， 正 常 显示 了 输入 的 字符 串 。 第 二 次 输 
入 结束 之 前 ， 按 Ctrl+C 键 ， 系 统 会 向 进程 发 送 SIGINT 信 号 ， 进 程 收 到 信号 后 ， 执 行 了 信和 号 处 理 函 数 
(打印 出 了 OMG，Icatch the signal SIGINT) ， 再 次 向 进程 发 送 SIGINT 信 号 ， 进 程 就 退出 了 。 











可 见 ， 在 SystemV 风 格 的 信号 处 理 机 制 中 ， 安 装 的 信号 处 理 函 数 是 一 次 性 的 ， 内 核 把 信号 递送 出 去 
后 ， 信 和 号 处 理 函 数 恢 复 成 默认 值 SIG_DFL。 因 为 SIGINT 信 和 号 的 默认 处 理 是 终止 进程 ， 所 以 进程 就 退出 
了 。 

















Linux 系 统 调用 也 是 如 此 ， 信 和 号 处 理 函 数 同样 是 一 次 性 的 : 





manu@manu-hacks:signal$ ./systemcall _ signal 
input a string: 
hello 
you entered:hello 

manu@manu-hacks:signal$ ./systemcall signal 
input a string: 
hello^COMG , I catch the signal SIGINT 
ee 
manu@manu-hacks:signals$ 








对 于 这 种 风格 ， 内 核 中 有 个 很 形象 的 宏 来 描述 这 种 行为 模式 ， 即 SA_ONESHOT。 


System V 风 格 的 singal 处 理 机 制 就 像 图 6-1 中 这 种 老式 的 单 发 手枪 ， 每 次 射击 完 之 后 ， 都 要 重新 上 子 
弹 ， 即 信号 处 理 函 数 触 发 之 后 ， 要 想 重 复 触 发 ， 必 须 再 次 安装 信号 处 理 函 数 。 








图 6-1 单 发 手枪 ， 发射 完 毕 ， 需 要 重新 添加 子弹 








对 于 信号 而 言 ， 是 用 标志 位 来 控制 信号 的 ONESHOT 行 为 模式 的 ， 这 个 标志 位 是 : 





/架构 相 关 ， 对 于 


又 8 6 平台 


二 
#define SA RESETHAND Ox80000000u 
#define SA ONESHOT SA RESETHAND 

















数 : 


当 内 核 递 送信 号 给 进程 时 ， 如 果 发 现 同 时 满足 以 下 两 个 条 件 ， 则 会 将 信和 号 处 到 





信号 处 理 函 数 不 是 默认 值 。 


.信号 处 理 函 数 的 标志 位 中 ，SA_ONESHOT 标 志 置 位 。 


这 部 分 控制 逻辑 ， 出 现 于 内 核 的 get signal to_deliver 函 数 中 : 








E 





函数 恢复 成 默认 冰 





int get signal to deliver(siginfo t *info, struct k sigaction *return ka, 
struct pt regs *regs, void *cookie) 


{ 


if (ka->sa.sa handler == SIG IGN) 


continue; 


if (ka->sa.sa handler != SIG DFL) 


/* Run the handler. */ 
*return ka = *ka; 





if (ka->sa.sa flags & SA ONESHOT) 
ka->sa.sa handler = SIG DFL; 
break; /* will return non-zero "signr" value */ 


/* Do nothing. 





使 用 strace 来 这 踪 sysv_signal 的 执行 ， 可 以 看 到 有 如 下 的 系统 调用 : 





Pn 





rt sigaction(SIGINT, {0x8048756, [], SA INTERRUPTSA NODEFER|SA RESETHAND}, {SIG DFL, 


[], 0}, 8) = 0 








BSD 风 格 的 signal 和 8glibc 的 signal 函 数 已 经 不 在 在 ONESHOT 的 问题 了 ， 代 码 如 下 所 示 : 





manu@manu-hacks:signal$ ./bsd signal 
input a string: 

hello^COMG , I catch the signal SIGINT 
^COK, finished Process signal SIGINT 
OMG , I catch the signal SIGINT 
OK, finished process signal SIGINT 
^COMG , I catch the signal SIGINT 
OK, finished process signal SIGINT 
manu@manu-hacks:signals$ ./glibc signal 
input a string: 

hello^COMG , I catch the signal SIGINT 
^COK, finished Process signal SIGINT 
OMG , I catch the signal SIGINT 
^COK, finished process signal SIGINT 
OMG , I catch the signal SIGINT 
OK, finished process signal SIGINT 














通过 strace 追 踪 bsd_signal 和 slibc_signal 执 行 的 系统 调用 ， 可 以 看 到 ， 两 者 调用 rt sigaction 系 统 调用 
时 都 没有 设置 SA_ONESHOT 的 标志 位 。 








rt sigaction (SIGINT, {0x8048736, [INT], SA RESTART}, {SIG DFL, [], 0}, 8) = 0 


OO 注意 “通过 strace 追 踪 bsd_signal 和 slibc_signal 可 以 看 出 ， 两 者 都 调用 了 rt _sigaction 系 统 调 
用 ， 并 且 参 数 完全 一 致 ， 表 明 在 我 的 机 器 上 ，sglibc 的 signal 函 数 使 用 了 BSD signal 的 语义 。 但 是 由 于 
signal 函 数 历史 悠久 ， 源 远 流 长 ， 在 不 同 的 平台 上 signal 函 数 的 语义 可 能 并 不 相同 。 在 相同 的 Linux 平 台 
上 ， 由 于 glibc 版 本 的 差异 ， 提 供 的 signal 函 数 的 语义 也 有 差异 。 在 早期 的 libc4 和 1libc5 中 ，signal 函 数 的 语 
义 是 Syetem V 风 格 的 。 因 此 ， 从 可 移植 的 角度 来 看 ， 不 应 该 使 用 signal 冰 数 。 




















6.5.2 ”信号 执行 时 屏 珊 上 自身 的 特性 








在 执行 信号 处 理 函 数 期 间 ， 很 有 可 能 会 收 到 其 他 的 信和 号， 当然 也 有 可 外 
号 。 如 果 在 处 理 A 信 号 期 间 再 次 收 到 A 信 号 ， 会 发 生 什 么 呢 ? 





再 次 收 到 正在 处 理 的 信 


By 














对 于 传统 的 System V 信 号 机 制 ， 在 信号 处 理 期 间 ， 不 会 屏蔽 对 应 的 信号 ， 而 这 就 会 引起 信号 处 理 函 
数 的 重 入 。 这 算是 传统 的 System V 信 号 机 制 的 另 一 个 次 端 了 。BSD 信 号 处 理 机 制 修正 了 这 个 缺陷 。 当 然 
了 ，BSD 信 号 处 理 机 制 只 是 屏蔽 了 当前 信号 ， 并 没有 屏蔽 当前 信号 以 外 的 其 他 信号 


























来 比较 下 System V 和 BSD signal 机 制 的 区 别 。 


System V 风 格 的 系统 调用 : 


rt sigaction (SIGINT, {0x8048756, [], SA_INTERRUPT|SA NODEFER|SA RESETHAND}, {SIG DFL, Liz QF 8) 各 
BSD 风 格 的 系统 调用 : 
rt sigaction (SIGINT, {0x8048736, [INT], SA _ RESTART}, {SIG DFL, [], 0}, 8) = 0 





在 上 面 的 输出 中 ， 中 括号 内 的 是 信号 执行 期 间 需 要 暂时 屏 敬 的 信号 。 











BSD 风 格 的 信号 处 理 机 制 ， 在 安装 信号 的 时 候 ， 会 将 自身 这 个 信号 添加 到 信号 处 理 函 数 的 屏蔽 集 
合 中 。 如 果 在 执行 A 信 号 的 信号 处 理 函 数 期 间 ， 再 次 收 到 A 信 号 ， 那 么 当前 的 A 信 和 号 处 理 流 程 则 不 会 被 
新 来 A 信 号 打 断 。 简 单 地 说 ， 就 是 不 会 嵌 套 了 。 


























System V 风 格 的 信号 ， 在 其 信号 处 理 期 间 没有 屏蔽 任何 信号 ， 换 句 话说 ， 执 行 信号 处 理 函数 期 间 ， 
处 理 流程 可 以 被 任意 信号 中 断 ， 包 括 正在 处 理 的 信和 号。 














从 前 面 的 实验 可 以 看 出 ，BSD 风 格 的 信号 处 理 函数 “OMG，Icatch the signal SIGINT”， 以 
及 “OK，finished process signal SIGINT”* 总 是 成 对 出 现 的 ， 不 可 能 连续 出 现 两 个 “OMG,， I catch the signal 
SIGINT”， 原 因 就 是 SIGINT 信 和 号 在 信号 处 理 函 数 执行 期 间 被 暂时 屏蔽 了 。 








内 核 是 如 何 做 到 这 一 点 的 ? 


完整 的 信和 号 递送 流程 大 致 如 此 : 内 核 首 先 调 用 get signal to_deliver， 在 挂 起 的 信号 集合 中 选择 一 个 
言 号 ， 递 送 给 进程 ， 选 择 完 毕 后 ， 调 用 handler_signal 函 数 。handler_signal 函 数 的 作用 是 为 执行 信号 处 理 
函数 做 准备 。 





void handler signal (int sig, siginfo t *info, struct k sigaction *ka, 


struct pt regs *regs int stepping) 
sigset t blocked; 


clear restore sigmask(); 
sigorsets(&blocked, &current->blocked, &ka->sa.sa mask); 
if (!(ka->sa.sa flags & SA NODEFER)) 

sigaddset (&blocked, sig); 
set current blocked(&blocked); 
tracehook signal handler(sig, info, ka, regs, stepping); 


从 上 面 代码 中 不 难看 出 ， 如 果 信 号 没有 设置 SA_NODEFER 标 志 位 ， 正 在 处 理 的 信号 就 必须 在 信号 
处 理 程序 执行 期 间 被 阻塞 。 




















System V 风 格 的 signal 机 制 为 何 会 出 现 不 屏蔽 自身 信号 的 情况 ? 原因 就 是 sysv_signal 函 数 ， 在 调用 
rt_sigaction 系 统 调用 时 加 上 了 SA_NODEFER 标 志 位 ， 如 下 : 


rt sigaction (SIGINT, {0x8048756, [], SA INTERRUPT|SA NODEFER 


|SA RESETHAND}, {SIG DFL, [], 0}, 8) = 0 


6.5.3 ”信号 中 断 系统 调用 的 重启 特性 
































系统 调用 在 执行 期 间 ， 很 可 能 会 收 到 信号 ， 此 时 进程 可 能 不 得 不 从 系统 调用 中 返回 ， 去 执行 信号 处 理 函 数 。 对 于 执行 时 间 比 较 久 的 系统 调 
] 《如 wait、read 等 ) 被 信号 中 断 的 可 能 性 会 大 大 增加 。 系 统 调用 被 中 断后 ， 一 般 会 返回 失败 ， 并 置 错误 码 为 EINTR。 
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如 果 程 序 员 希望 处 理 完 信号 之 后 ， 被 中 断 的 系统 调用 能 够 重启 ， 则 需要 通过 判断 errno 的 值 来 解决 ， 即 如 果 发 现 错误 码 是 EINTR， 就 重新 调 
用 系统 调用 。 来 看 下 面 的 例子 





























manu@manu-hacks:~/code/c/self/signal$ ./sysv signal 
input a string: 本 

^COMG , I catch the signal SIGINT 

OK, finished process signal SIGINT 

fgets failed(Interrupted System call) 









































通过 strace 可 以 看 到 ，fgets 调 用 了 read 系 统 调 用 ， 而 read 系 统 调用 因为 等 待 用 户 输入 而 陷入 长 时 间 的 阻塞 。 在 阻塞 过 程 中 ， 收 到 了 一 个 
SIGINT 信 号 ， 导 致 read 系 统 调用 被 中 断 ， 返 回 了 错误 码 EINTR 。 
















































































Linux 世 界 中 的 很 多 系统 调用 都 会 遭遇 这 种 情景 ， 尤 其 是 read、wait 这 种 可 能 比较 耗 时 的 系统 调用 。《Unix 系 统 编程 : 通信 、 并 发 和 线程 》 一 
书 中 存在 很 多 类 似 的 例子 : 


























pid t r waitl(int *stat loc) 
{ 


int retval; 
while(((retval = wait(stat loc)) ==-1 && (errno == EINTR) ){ 


} 
return retval; 


} 

















这 种 封装 就 是 用 来 应 对 系统 调用 被 信号 中 断 的 场景 的 。 当 系统 调用 被 信号 中 断 时 ， 程 序 并 不 认为 这 是 一 种 无 法 处 理 的 错误 ， 相 反 ， 程 序 完 
全 可 以 通过 重新 调用 系统 调用 ， 来 完成 其 想 做 的 事情 。 
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在 System V 信 号 机 制 下 ， 系 统 调 用 如 果 被 信号 中 断 ， 则 会 返 














-1， 置 errno 为 EINTR， 而 不 会 主动 重启 被 信号 中 断 的 系统 调用 。 
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细 想 来 ， 如 果 所 有 的 系统 调用 都 要 判断 返回 值 是 否 为 EINTR， 是 的 话 ， 则 重启 系统 调用 ， 那 么 程序 员 就 太 累 了 。BSD 风 格 的 signal 机 制 提 
供 了 另外 一 种 思路 ， 即 如 果 系 统 调用 被 信号 中 断 ， 内 核 会 在 信号 处 理 函数 结束 之 后 ， 自 动 重启 系统 调用 ， 无 须 程序 员 再 次 调用 系统 调用 。 


































































































































































































Linux 操 作 系 统 提 供 了 一 个 标志 位 SA_RESTART 来 告诉 内 核 ， 被 信号 中 断后 是 否 要 重启 系统 调用 。 如 果 该 标志 位 为 1， 则 表示 如 果 系 统 调用 被 
信号 中 断 ， 那 么 内 核 会 自动 重启 系统 调用 。 
BSD 风 格 的 signal 函 数 和 8glibc 的 函数 ， 训 无 意外 地 都 带 有 该 标志 位 : 
rt_sigaction (SIGINT, {0x8048736, [INT], SA RESTART}, {SIG DFL, [], 0}, 8) = 0 
1 于 BSD 风 格 的 signal 存 在 这 个 标志 SA_RESTART， 因 此 fgets 不 会 像 System V 的 signal 一 样 ， 返 回 错误 码 : 






































manu@manu-hacks:~/code/c/self/signal$ ./bsd signal 
input a string: 
hello^COMG , I catch the signal SIGINT 

OK, finished process signal SIGINT 

^COMG , I catch the signal SIGINT 

OK, finished process signal SIGINT 












































非常 不 季 的 是 ， 并 不 是 所 有 的 系统 调用 对 信号 中 断 都 表现 出 同样 的 行为 。 某 些 系 统 调用 哪怕 设置 了 SA_RESTART 的 标志 位 ， 也 绝 不 会 自动 








上 中 
mam 
































ml 
Tm 


























那么 问题 就 来 了 ， 在 Linux 下 ， 如 果 信 号 处 理 函 数 设置 了 SA_RESTART， 哪 些 阻 塞 型 的 系统 调用 遭 到 信号 中 断后 ， 可 以 自动 
调用 又 是 死活 也 无 法 自动 重启 的 呢 ? 








启 ， 哪 些 系统 












































表 6-9 列 出 了 设置 SA_RESTART 标 志 位 后 ， 可 以 自动 重启 的 阻塞 型 系统 调用 。 





























表 6-9 ”设置 了 SA RESTART 标 志 位 ， 中 断后 可 以 自动 














mm 











启 的 系统 调用 























Tead write Teadv writev 






waitid 


recvfrom (没有 设置 超时 ) 


没有 设置 connect (没有 设置 超时 ) recv (没有 设置 超时 ) 


sendto (没有 设置 超时 ) 


sendmsg (没有 设置 超时 ) fcntl: F SETLKW mq receive 














表 6-10 是 设置 了 SA_RESTART 标 志 位 ， 也 不 会 重启 的 系统 调用 。 












































表 6-10 设置 了 SA_RESTART 标 志 位 ， 中 断后 也 无 法 自动 重启 的 系统 调用 





























epoll walt epoll pwait msgsnd 
semop clock nanosleep nanosleep 


usleep accept (有 设置 超时 ) connect (有 设置 超时 ) recv (有 设置 超时 ) 
recvfrom (有 设置 超时 ) recvmsg (有 设置 超时 ) send (有 设置 超时 ) sendto (有 设置 超时 ) 


太 多 了 ， 记 不 住 怎么 办 ? man 来 帮忙 。 通 过 man 7 signal 就 可 以 获得 这 些 信息 。 














通过 前 面 三 节 的 测试 ， 可 以 得 到 表 6-11 中 的 结论 。 
































表 6-11 4 种 信号 函数 的 不 同 表现 


| 


言 号 机 制 是 否 有 ONESHOT 特性 | 执行 期 间 是否 屏 蔽 自身 信号 


BSD 


























是 否 重启 系统 调用 
NO 
YES 
NO 
YES 











手册 明确 表示 bsd_signal 没 有 ONESHOT 特 性 ， 信 号 处 理 函数 不 会 reset 成 默认 值 ， 无 须 重复 安装 信号 处 理 函 数 ， 信 号 处 理 函 数 期 间 ， 自 身 信号 
会 被 屏蔽 ， 系 统 调用 被 中 断 ， 会 重启 系统 调用 。 这 三 个 特性 都 是 可 以 保证 的 ， 但 是 glibc 下 signal 函 数 就 不 一 定 了 ， 这 要 取决 于 操作 系统 ， 取 决 于 






























































glibc 的 版 本 。 这 是 signal 函 数 被 人 诉 病 的 一 个 重要 原因 。 简 言 之 ， 就 是 其 历史 负担 太 习 


中 
o 























通过 前 面 的 讨论 可 以 发 现 ，Linux 系 统 会 通过 一 些 标志 位 和 屏蔽 信号 集 来 完成 对 某 些 特性 的 控制 。 


























.SA_ONESHOT (或 SA_RESERTHAND) : 将 信号 处 理 函 数 恢复 成 默认 值 。 








:SA_NODEFER (或 SA NOMASK) : 显 式 地 告诉 内 核 ， 不 要 将 当前 处 理 信 号 值 添 加 进 阻塞 信号 集 。 





























只 
nm 





-SA RESTART: 将 中 断 的 系统 调 








启 ， 而 不 是 返回 错误 码 EINTR。 




















6.6 ”信号 的 可 人 靠 性 








6.4 节 讲 信号 的 分 类 时 提 到 过 ， 传 统 的 信号 存在 信号 丢失 的 问题 ， 因 此 被 称 为 不 可 靠 信号 。 为 了 对 
传统 的 不 可 靠 信 号 有 更 直观 的 认识 ， 下 面 来 做 一 个 简单 的 实验 ， 让 事实 来 说 话 。 我 们 可 以 疯狂 地 向 茶 
个 进程 发 送信 号 ， 然 后 通过 比较 信号 发 送 的 次 数 和 信和 号 处 理 函 数 执行 的 次 数 来 验证 是 否 存在 信号 丢失 
的 问题 。 

















6.6.1 信号 的 可 徘 性 实验 





言 号 作为 一 种 进程 间 的 通信 方式 ， 会 期 望 发 射 N 次 信号 ， 那 么 目标 进程 就 执行 信号 处 理 函 数 N 
次 。 对 于 传统 信号 而 言 ， 实 际 情况 又 如 何 呢 ? 来 看 看 下 面 的 示例 代码 : 














#include <stdio.h> 

#include <stdlib.h> 

#include <unistd.h> 

#include <signal.h> 

#include <string.h> 

#include <errno.h> 

static int sig cnt [NSIG]; 

static volatile sig atomic t get SIGINT = 0; 
void handler (int signo) 


if(signo == SIGINT) 
get SIGINT = 1; 
else 
sig cnt[signo]++; 
int main(int argc,char* argv[]) 


int i = 0; 





sigset t blockall mask ; 
sigset t empty mask ; 
printf("%s:PID is %d\n",argv[0],getpid()); 
for(i = 1; i < NSIG; i++) 
{ 
if(i == SIGKILL || i == SIGSTOP || 
= 32. 11 .4s 33) 
continue; 
if (signal (i,&handler) == SIG ERR) 
{ 


fprintf (stderr,"signal for signo(%d) failed (%s)\n", 
i,strerror (errno)); 
} 
} 
ifl(largc > 1) 


int Sleep time = atoi (argv[1]); 

sigfillset (&blockall mask); 

if (sigprocmask (SIG SETMASK, &blockall mask,NULL) == -1) 
{ 


fprintf (stderr,"setprocmask to block all signal failed(%s)\n", 
strerror (errno)); 
return -2; 


printf ("I will sleep %d second\n",sleep time); 
sleep (sleep time); 

sigemptyset (&empty mask); 

if (sigprocmask (SIG SETMASK, &sempty mask,NULL) == -1) 
{ 





fprintf (stderr,"setprocmask to release all signal failed(%$s)\n", strerror (errno)); 
EE =33 


} 


} 
while(!get SIGINT) 

continue ; 
printf("%$-10s%$-1l0s\n", "signo", "times"); 
printf (N= Nn) 
EGr (l= TF 和 攻 NSIG 3; 主 夺 证) 
{ 

if(sig cnt[il] = 0 ) 


printf ("%$-10d%s-10d\n",i,sig cnt[i]); 


return 0; 





下 面 来 简单 讲述 这 个 程序 。 





如 果 执 行 时 不 带 参 数 ， 那 么 进程 会 原 地 循环 ， 直 到 收 到 SIGINT 信 号 为 止 。 在 这 期 间 ， 信 号 处 理 孙 
数 每 执行 一 次 ， 都 会 将 收 到 信号 的 次 数 加 1， 进 程 结束 前 ， 会 将 各 种 信号 收 到 的 次 数 打 印 出 来 。 











如 果 执 行 时 带 一 个 参数 ， 那 么 这 个 参数 的 含义 是 屏蔽 信号 的 时 间 N， 首 先 将 能 够 阻塞 的 信号 全 部 阻 
塞 ， 在 信号 阻塞 期 间 ， 虽 然 会 有 进程 向 signal receiver 进 程 发 送信 号 ， 但 是 内 核 并 不 会 立即 将 收 到 的 信 











号 递送 给 进程 。 在 沉睡 N 秒 之 后 ， 解 除 阻 塞 ， 内 核 开 始 向 Signal_receiver 进 程 递送 信号 。 





再 准备 一 个 发 送信 号 的 程序 : 


#include <stdio.h> 

#include <stdlib.h> 
#include <getopt.h> 
#include <signal.h> 
#include <string.h> 
#include <errno.h> 

void usage () 


fprintf (stderr, "USAGE: \n"); 
Forintt (stderr 全 AS \n"); 
fprintf (stderr,"signal sendqer pid signo times\n"); 
} 
int main(int argc,char* argv[]) 


{ 


pid t pid = -1 ，) 
int signo = -1; 
int times = -1; 
i 二 冰 


if(largc < 4) 
{ 

usage (); 

return -1; 
} 
pid = atol (argv[1]); 
signo = atoi (argv[2]); 
times = atoi (argv[3]); 


if(pid <= 0 || times < 0 || signo <1 || 
signo >=64 ||signo == 32 || signo ==33) 
{ 
usage (); 


return -1; 
} 
printf ("pid = %d,signo = %d,times = S$d\n",pid,signo,times); 
for(i=0; i < times ; i++) 
{ 
if (kill (pid,signo) == -1) 
{ 


fprintf (stderr, "send signo(%d) to pid(%d) failed,reason(%$s)\n", 
signo,pid,strerror (errno)); 
return -2; 
} 
} 
fprintf (stdout, "done\n"); 
return 0; 














程序 比较 简单 ， 接 受 三 个 参数 : 目标 进程 号 、 信 号 值 和 发 送 次 数 。 有 了 这 个 工具 ， 我 们 可 以 向 目 








标 进 程 signal_receiver 连 续 发 送 任 意 次 数 的 信号 X。 


首先 ，signal receiver 不 带 参数 执行 〈 即 signal receiver 进 程 不 会 让 信号 阻塞 一 段 时 间 ) ， 向 
Signal _ receiver 连 续 发 送信 号 ， 看 看 目标 进程 signal_ receiver 一 共 收 到 多 少 次 信和 号 











manuQmanu-hacks:signal$ ./signal receiver 
./signal receiver:PID is 9937 


然后 发 送 SIGINT 信 号 1 次 来 结束 signal _ receiver 进程， 下 了 








向 9937 进 程 发 送信 号 SIGUSR210000 次 ， 
查看 signal receiver 进 程 一 共 收 到 多 少 次 信和 号 
此 


manu@manu-hacks:signal$ ./signal sender 9937 12 10000 
pid = 9937,signo = 12,times = 10000 
done 

manu@manu-hacks:signal$ ./signal sender 


pid = 9937,signo = 2,times = 1 


9937 这 -了 1 





signal_receiver 进 程 打印 结果 为 : 
































i , 
Signo Ees 
12 2488 
可 以 看 到 我 们 发 送 12 号 信号 10000 次 ， 可 是 signal_ receiver 只 收 到 2488 次 ， 这 个 2488 也 不 是 固定 的 ， 
如 果 多 执行 几 次 ， 你 会 看 到 每 次 收 到 的 信号 次 数 均 不 相同 ， 如 下 : 
signo i 
I 2 
Signo ee 
12 2403 
可 以 看 到 收 到 信号 的 次 数 是 不 一 定 的 ， 但 是 都 不 等 于 发 送信 号 的 次 数 。 再 进一步 ， 让 信号 接收 进 
程 屏 蔽 信号 一 段 时 间 ， 在 这 段 时 间 内 ， 发 送信 号 ， 查 询 信 号 处 理 函数 被 触发 的 次 数 : 
1 


manu@manu-hacks:signal$ ./signal receiver 30 
./signal receiver:PID is 27639 
I will sleep 30 second 终 端 


2 
manuQ@manu-hacks:signals$ 
pid = 27639,signo = 10,times = 
done 
manu@manu-hacks:signals 


./signal sender 27639 10 10000 
10000 


./signal sender 27639 36 10000 


pid = 27639,signo = 36,times = 10000 
done 终 端 

1 

signo times 

10 I 

36 10000 


从 上 面 的 例子 可 以 看 出 ， 如 果 进 程 将 信号 屏蔽 一 段 时 间 ， 在 此 期 间 向 目标 进程 发 送 SIGUSR2 信 号 
10000 次 ， 在 解除 屏蔽 之 后 ， 信 和 号 处 理 函 数 只 触发 了 一 次 。 






































那么 可 靠 信号 的 表现 又 如 何 呢 ? 实验 中 发 送 实时 信号 36 共 计 10000 次 ， 解 除 屏蔽 后 信号 处 理 函 数 共 
触发 了 10000 次 ， 没 有 丢失 信号 ， 所 有 信号 都 被 递送 给 进程 去 处 理 了 。 



































6.6.2 ”信号 可 靠 性 过 异 的 根源 














从 上 面 的 实验 可 以 看 出 可 靠 信 号 和 不 可 靠 信 号 存在 着 不 小 的 差异 。 不 可 靠 信 与 ， 不 能 可 靠 地 被 传 
递 给 进程 处 理 ， 内 核 可 能 会 丢弃 部 分 信号 。 会 不 会 丢弃 ， 以 及 丢弃 多 少 ， 取 决 于 信号 到 来 和 信号 递送 
给 进程 的 时 序 。 而 可 靠 信 号 ， 基 本 不 会 丢失 信和 号。 

















之 所 以 存在 这 种 差异 ， 是 因为 重复 的 信和 号 到 来 时 ， 内 核 采取 了 不 同 的 处 理 方式 。 从 内 核 收 到 发 给 
某 进 程 的 信号 ， 到 内 核 将 信号 递送 给 该 进程 ， 中 间 有 个 时 间 窗 口 。 在 这 个 时 间 窗 口内 ， 内 核 会 负责 记 
录 收 到 的 信号 信息 ， 这 些 信号 被 称 为 挂 起 信号 或 未 决 信号 。 但 是 对 于 可 靠 信号 和 不 可 靠 信号 ， 内 核 采 
取 了 不 同 的 记录 方式 。 









































内 核 中 负责 记录 挂 起 信号 的 数据 结构 为 sigpending 结 构 体 ， 定 义 代码 如 下 : 








struct sigpending { 
struct list head list; 
sigset t signal; 
}; 
#define NSIG 64 
#define NSIG BPW 64 
#define NSIG WORDS ( NSIG / _NSIG BPW) 
typedef struct { 
unsigned long sig[_ NSIG WORDS]; 
} sigset t; 














在 sigpending 结 构 体 中 ，sigset t 类 型 的 成 员 变 量 signal 本 质 上 是 一 个 位 图 ， 用 一 个 比特 来 记录 是 否 存 
在 与 该 位 置 对 应 的 信号 处 于 未 决 的 状态 。 根 据 位 图 可 以 有 效 地 判断 某 信号 是 否 已 经 存在 未 决 信号 。 因 
为 共有 64 种 不 同 的 信号 ， 因 此 对 于 64 位 的 操作 系统 ， 一 个 无 符号 的 长 整 型 就 足以 描述 所 有 信号 的 挂 起 
情况 了 。 














在 sigpending 结 构 体 中 ， 第 一 个 成 员 变 量 是 个 链表 头 。 内 核定 义 了 结构 体 sigqueue， 代 码 如 下 : 





struct sigqueue { 
struct list head list; 
int flags; 
siginfo t info; 
struct user struct *user; 

















该 结构 体 中 info 成 员 变 量 详细 记录 了 信号 的 信息 。 如 果 内 核 收 到 发 给 某 进程 的 信号 ， 则 会 分 配 一 个 
sigqueue 结 构 体 ， 并 将 该 结构 体 挂 入 sigpending 中 第 一 个 成 员 变 量 list 为 表 头 的 链表 之 中 。 


























综 上 所 述 ， 内 核 的 进程 描述 符 提 供 了 两 套 机 制 来 记录 挂 起 信号 : 位 图 和 队列 。 可 能 有 读者 会 问 ， 
存在 两 套 机 制 ， 尤 其 是 存在 队列 ， 不 应 该 丢失 信号 啊 ! 正常 来 讲 ， 来 一 个 信号 ， 只 须 将 信号 的 相关 信 
息 挂 入 队列 之 中 ， 就 可 以 确保 信号 不 丢 。 的 确 如 此 ， 但 是 实际 上 ， 可 靠 信 号 和 不 可 靠 信 号 的 处 理 方式 
不 同 ， 不 可 靠 信号 并 没有 充分 的 队列 来 确保 信号 不 丢 。 























内 核 收 到 不 可 靠 信号 时 ， 会 检查 位 图 中 对 应 位 置 是 否 已 经 是 1， 如 果 不 是 1， 则 表示 尚 无 该 信号 处 
于 挂 起 状态 ， 然 后 会 分 配 sigqueue 结 构 体 ， 并 将 信号 挂 入 链表 之 中 ， 同 时 将 位 图 对 应 位 置 置 1。 但 是 如 
果 位 图 显示 已 经 存在 该 不 可 靠 信号 ， 那 么 内 核 会 直接 丢弃 本 次 收 到 的 信号 。 换 句 话说 ， 内 核 的 
sigpending 链 表 之 中 ， 最 多 只 会 存在 一 个 不 可 靠 信 号 的 sigqueue 结 构 体 。 




















内 核 收 到 可 靠 信 号 时 ， 不 论 是 否 已 经 存在 该 信号 处 于 挂 起 状态 ， 都 会 为 该 信号 分 配 一 个 sigqueue 结 
构 体 ， 并 将 sigqueue 结 构 体 挂 入 sigpending 的 链表 之 中 ， 以 确保 不 会 丢失 信号 。 








那么 可 靠 信 号 是 不 是 可 以 无 限制 地 挂 入 队列 昵 ? 也 不 是 。 实 际 上 内 核 也 做 了 限制 ， 一 个 进程 默认 
挂 起 信号 的 个 数 是 有 限 的 ， 超 过 限制 ， 可 靠 信号 也 会 变 得 没 那么 可 牧 了 ， 也 会 丢失 信号 。 让 我 们 看 看 
内 核 代码 : 








static struct sigqueue * 
__SsSigqueue alloc(int sig, struct task struct *t, gfp t flags, int override rlimit) 


struct sigqueue *q = NULL; 
StEuCt. User StruCt. user 


rcu read lock(); 
user = get uid( task cred(t)->user); 
atomic inc(&user->sigpending); 
rcu read unlock(); 
if (override rlimit || 
atomic read(&user->sigpending) <= 


task rlimit(t, RLIMIT SIGPENDING) 


q = kmem cache alloc(sigqueue cachep, flags); 
} else { 
print dropped signal (sig); 


} 

if (unlikely(q == NULL)) { 
atomic dec(&user->sigpending); 
free uid(user); 

} else { 
INIT LIST HEAD(&q->list); 
q->flags = 0; 
qdq->user = user; 


return qs; 





加 粗 部 分 的 逻辑 ， 决 定 了 实时 信号 也 不 能 被 无 限制 地 挂 起 。 该 限制 属于 资源 限制 的 范畴 ， 该 限制 
项 (RLIMIT_SIGPENDING)〉 限制 了 目标 进程 所 属 的 真实 用 户 ID 信和 号 队列 中 挂 起 信号 的 总 数 。 


























可 以 通过 如 下 命令 来 查看 系统 的 限制 ; 


manu@manu-hacks:~$ ulimit - 


a 


pending signals (i) 15144 











用 上 面 的 测试 程序 测试 一 下 ， 看 看 实时 信号 是 否 也 会 丢失 信号: 





manu@manu-hacks:signal$ ./signal receiver 30 
./signal receiver:PID is 14699 
I will sleep 30 second 终 端 


2 

manu@manu-hacks:signal$ ./signal sender 14699 36 20000 
pid = 14699,signo = 36,times = 20000 

done 

manu@manu-hacks:signal$ ./signal sender 14699 2 1 
pid = 14699,signo = 2,times = 1 

done 

manuemanu-hacks :signal$ 终 端 


1 
signo times 
36 15144 








和 预期 的 一 样 ， 向 目标 进程 发 送 了 实时 信和 号 36 共 计 20000 次 ， 但 目标 进程 只 收 到 了 15144 次 ， 超 出 
限制 的 部 分 都 被 丢弃 掉 了 。 











这 个 挂 起 信号 的 上 限 值 是 可 以 修改 的 ， 可 以 用 ulimiti unlimited 这 个 命令 将 进程 挂 起 信号 的 最 大 值 
设 为 无 穷 大 ， 从 而 确保 内 核 不 会 主动 丢弃 实时 信号。 








6.7 信号 的 安装 





前 面 讲 了 传统 信号 的 很 多 次 端 ， 讲 了 signal 的 兼容 性 问题 ， 有 问题 就 会 有 解决 方案 。 对 此 ，Linux 提 
供 了 新 的 信号 安装 方法 : sigaction 函 数 。 和 signal 函 数 相 比 ， 这 个 函数 的 优点 在 于 语义 明确 ， 可 以 提供 
更 精确 的 控制 。 

















先 来 看 一 下 sigaction 函 数 的 定义 : 





#include <signal.h> 

int sigaction(int signum, const struct sigaction *act, 
struct sigaction *oldact); 

struct Sigaction 4 


void (*sa handler) (int); 

void (*sa sigaction) (int, siginfo t *, void *); 
sigset t sa mask; 

int sa flags; 

void (*sa_ restorer) (void); 





上 面 给 出 的 sigaction 结 构 体 的 定义 并 非 严 格 意义 上 的 定义 ， 即 结构 体 必须 要 有 上 述 的 成 员 变 量 ， 但 
成 员 变 量 的 具体 顺序 取决 于 实现 。 




















顾名思义 ，sa_mask 就 是 信号 处 理 函 数 执行 期 间 的 屏蔽 信号 集 。 前 文 介 绍 bsd_signal 的 时 候 曾 提 到 ， 
为 SIGINT 安 装 处 理 函 数 时 ， 内 核 会 自动 将 SIGINT 添 加 入 屏蔽 信号 集 ， 在 SIGINT 信 号 处 理 函 数 执行 期 
间 ，SIGINT 信 和 号 不 会 被 递送 给 进程 。 但 是 ， 也 仅仅 是 SIGINT， 如 果 执 行 SIGINT 信 号 处 理 函 数 期 间 ， 需 
要 屏蔽 SIGHUP、SIGUSR1 等 其 他 信号 ， 那 bsd_signal 函 数 就 爱 莫 能 助 了 。 这 个 屏蔽 其 他 信号 的 需求 对 
sigaction 函 数 而 言 ， 根 本 就 不 是 问题 ， 只 需 如 下 代码 即 可 做 到 : 



































struct sigaction sa: 


sa.sa mask = SIGHUP|SIGUSR1 |SIGINT; 


需要 特别 指出 的 是 ， 并 不 是 所 有 的 信和 号 都 能 被 屏蔽 。 对 于 SIGKILL 和 SIGSTOP， 不 可 以 为 它们 安装 
音 号 处 理 函 数 ， 也 不 能 屏蔽 掉 这 些 信 号 。 原 因 是 ， 系 统 总 要 控制 某 些 进程 ， 如 果 进 程 可 以 自行 设计 所 
有 信和 号 的 处 理 函数 ， 那 么 操作 系统 可 能 无 法 控制 这 些 进 程 。 换 言 之 ， 操 作 系统 是 终极 boss， 需 要 杀 死 某 
些 进 程 的 时 候 ， 要 能 够 做 到 ，SIGKILL 和 SIGSTOP 不 能 被 屏蔽 ， 就 是 为 了 防止 出 现 进程 无 法 无 天 而 操作 
系统 徒 叹 奈何 的 困境 
































OO 注意 ”SIGKILL 和 SIGSTOP 也 不 是 万 能 的 。 如 果 进 程 处 于 TASK_UNINTERRUPTIBLE 的 状 
态 ， 进 程 就 不 会 处 理 信号 。 如 果 进 程 失控 ， 长 期 处 于 该 状态 ，SIGKILL 也 无 法 杀 死 该 进程 。 详 情 可 以 回 


顾 第 5 章 。 

















知 通过 sigaction 强 行 给 SIGKILEL 或 SIGSTOP 注 册 信号 处 理 函 数 ， 则 会 返回 -1， 并 置 errno 为 EINVAL。 








在 sigaction 函 数 接口 中 ， 比 较 有 意思 的 是 sa_flags。sigaction 函 数 之 所 以 可 以 提供 更 精确 的 控制 ， 大 
部 分 都 是 该 参数 的 功劳 。 下 面 简要 介绍 一 下 sa_flags 的 含义 ， 其 中 很 多 标志 位 并 不 是 新 面孔 ， 前 面 已 经 
讨论 过 了 。 




















(1) SA_NOCLDSTOP 





这 个 标志 位 只 用 于 SIGCHLD 信 号 。4.7 节 "等待 子 进程 ”中 曾经 提 到 过 ， 父 进程 可 以 监测 子 进程 的 三 
事件 : 











—>h 
= 
山中 


: 子 进程 终止 〈 即 子 进程 死亡 ) 


子 进程 停止 〈 即 子 进程 暂停 ) 











子 进 程 恢复 ( 即 子 进程 从 暂停 中 恢复 执行 ) 





其 中 SA_NOCLDSTOP 标 志 位 是 用 来 控制 第 二 种 和 第 三 种 事件 的 。 即 一 旦 父 进程 为 SIGCHLD 信 号 设 
置 了 这 个 标志 位 ， 那 么 子 进程 停止 和 子 进程 恢复 这 两 件 事情 ， 就 无 须 向 父 进程 发 送 SIGCHLD 信 号 了 。 

















(2) SA NOCLDWAIT 











这 个 标志 只 用 于 SIGCHLD 信 号 ， 它 可 控制 上 面 提 到 的 子 进程 终止 时 的 行为 。 如 果 父 进程 为 
SIGCHLD 设 置 了 SA_NOCLDWAIT 标 志 位 ， 那 么 子 进 程 退出 时 ， 就 不 会 进入 僵尸 状态 ， 而 是 直接 自行 了 
断 。 但 是 子 进 程 还 会 不 会 向 父 进程 发 送 SIGCHLD 信 和 号 呢 ? 这 取决 于 具体 的 实现 。 对 于 Linux 而 言 ， 仍 然 
会 发 送 SIGCHLD 信 号 。 这 点 和 上 面 的 SA_NOCLDSTOP 略 有 不 同 。 



































(3) SA_ONESHOT 和 SA_RESETHAND 








这 两 个 标志 位 的 本 质 是 一 样 的 ， 表 示 信 和 号 处 理 函 数 是 一 次 性 的 ， 信 号 递送 出 去 之 后 ， 信 和 号 处 理 函 
数 便 恢 复 成 默认 值 SIG_DFL。 

















(4) SA NODEFER 和 SA NOMASK 

















这 两 个 标志 位 的 作用 是 一 样 的 ， 在 信号 处 理 函 数 执 行 期 间 ， 不 阻塞 当前 信号 。 


(5) SA_RESTART 








这 个 标志 位 表示 ， 如 果 系 统 调用 被 信号 中 断 ， 则 不 返回 错误 ， 而 是 自动 重启 系统 调用 。 








(6) SA_SIGINFO 























这 个 标志 位 表示 信号 发 送 者 会 提供 额外 的 信息 。 这 种 情况 下 ， 信 号 处 理 函 数 应 该 为 三 参数 的 函 
数 ， 代码 如 下 : 














void handle (int, siginfo t *, void *); 














此 处 重点 讲述 一 下 带 SA_SIGINFO 标 志 位 的 信号 安 闭 方 式 。 本 章 引 言 中 提 到 过 ，signal 的 本 质 是 一 
种 进程 间 的 通信 。 一 个 进程 向 另外 一 个 进程 发 送信 号 ， 能 够 传递 的 信息 ， 不 仅仅 是 signo， 它 还 可 以 发 
送 更 多 的 信息 ， 而 接收 进程 也 能 获取 到 发 送 进程 的 PID、UID 及 发 送 的 额外 信息 。 











来 看 下 面 的 例子 : 


#include<stdio.h> 
#include<stdlib.h> 
#include<signal.h> 
void sig handler(int signo,siginfo 七 *info,void *context) 


printf 
printf 
区 让 从 巧 竺 
printf 


"\nget signal:%d\n",signo); 

"signal number is Sd\n",info->si signo); 
"pid=%$d\n", info->si pid); 

"sigval = %d\n",info->si value.sival int); 


int main (void) 


struct sigaction new action; 
sigemptyset (&new action.sa mask); 
new action.sa sigaction = sig handler; 
new action.sa .flags |= SA SIGINFO|SA RESTART; 
if (sigaction (36, &new action,NULL)==-1){ 
printf("set signal process mode\n") 
exit (1) ， 


} 

while (1) 
pause () ， 

printf ("Done\n") 

exit (0) ; 








这 个 例子 比较 简单 ， 为 36 号 信号 注册 了 信和 号 处 理 函 数 。 因 为 sa_flags 带 上 了 SA_SIGINFO 标 志 位 ， 所 
以 必须 使 用 三 参数 的 信号 处 理 函 数 。 























哮 


void sig handler(int signo,siginfo t *info,void *context) 














本 例 中 的 信号 处 理 函 数 中 ，info->si_pid 记 录 着 信号 发 送 者 的 PID，info->si_value.sival_int 是 信号 发 
送 进程 时 额外 发 送 的 int 值 。 发 送 进程 和 接收 进程 约定 好 ， 发 送 者 使 用 sigqueue 发 送信 号 ， 同 时 带 上 int 型 
的 额外 信息 ， 接 收 进程 就 能 获得 发 送 进 程 的 PID 及 int 型 的 额外 信息 。 











如 果 调 用 sigaction 函 数 时 ，sa_flags 带 了 SIGINFO 标 志 位 ， 那 么 进程 可 以 获得 哪些 信息 ? 6.8.3 小 节 介 
绍 sigqueue 函 数 时 ， 会 展开 讲述 。 





6.8 信号 的 发 送 


6.8.1 


kill、tkil 和 tekill 


Kill 函数 的 接口 定义 如 下 ; 








#include <sys/types.h> 
#include <signal.h> 


int kil]l (pid t pid, int sig); 





VY 
注 总 ， 























定 进程 组 发 送信 号 。 第 











不 能 望 文生 义 ， 将 kill 函数 的 作 
个 参数 pid 的 值 ， 决 定 了 kill 函 数 的 不 同 含义 ， 





pid>0: 发 送信 号 给 进 























:pid 二 0: 发 送信 号 给 调 














:pid 二 -1: 有 权限 向 调 ) 










































































用 理解 为 杀 死 进程 。kill 函 数 的 作 月 


肯 是 发 送信 号 。kill 
具体 来 讲 ， 可 以 分 成 以 1 




















程 ID 等 于 pid 的 进程 。 
进程 所 在 的 同一 个 进程 组 的 每 一 个 进程 。 
进程 发 送信 号 的 所 有 进程 发 出 信号 ，init 进 程 和 进程 自身 除外 。 





























-pid 二 -1: 向 进程 组 -pid 发 送信 号 。 





当 函 数 成 功 时 ， 返 回 0， 失 败 时 ， 返 











errno 


EINVAL 


EPERM 


ESRCH 























F 置 errno。 常 见 的 H 





互 
最 

上 

oe 




















即 调 


























有 一 种 情况 很 有 意思 ， 














b 错 情况 见 表 6-12。 


表 6-12 ”kill 函数 的 错误 码 及 说 明 


jkill 函 数 时 ， 第 二 个 参数 signo 的 值 为 0。 众 所 周知 ， 























星 组 是 否 存在 。 如 果 kill 函 数 返 回 























:是 真 的 向 目 





















































发 送信 号 的 





型 方法 如 下 : 


标 进程 或 进程 组 发 送信 号 ， 而 是 


的 进程 或 进程 组 并 不 存在 。 


j 来 检测 目标 进程 或 进 


说 有明 


无 效 的 信和 号 值 
该 进程 没有 权限 发 送信 号 给 目标 进程 
目标 进程 或 进程 组 不 存在 











没有 一 个 信号 的 值 是 为 0 的 ， 这 种 情况 下 ，kill 函 数 其 实 并 


函数 不 仅 可 以 向 特定 进程 发 送信 号 ， 也 可 以 向 特 
下 几 种 情况 。 





1 且 errno 为 ESRCH， 则 可 以 断定 我 们 关注 








if (kill (3423,SIGUSR1) 


/*error handler*/ 


} 


== -1) 





如 何 向 线程 发 送信 号 ? 














Linux 提 供 了 人 kl 和 tegkill 两 个 系统 调 

















] 来 向 某 个 线程 发 送信 号 : 





int tkill(int tid: int Sig)s 
int tqkill (int tgidy int tid;y int siyg}y 














这 两 个 都 是 内 核 提供 的 系统 调用 ， 





下 

















8glibc 并 没有 提供 


























对 这 两 个 系统 调用 








的 封装 ， 所 以 如 果 想 使 朋 























有 这 两 























jsyscall 的 方式 ， 如 











ret = syscall (SYS tkill]l,tid,sig) 


ret = syscall (SYS tgkill,tgid,tid, sig) 





等 一 下 ， 为 什么 有 了 tkill， 还 要 引入 tegkill? 





实际 上 ，tkill 是 一 个 过 时 的 接口 ， 关 























F 不 推荐 使 












































] 它 来 向 线程 发 送信 号 。 
线程 组 中 主线 程 的 线程 ID， 或 者 称 为 进程 号 。 这 个 参数 表面 看 起 来 是 多 余 的 ， 

















相 比 之 下 ，tgkill 接 

















更 加 安全 。 


tgkill 系 统 调用 的 第 一 个 参数 tgid， 为 

















其实 它 能 起 到 保护 的 作用 














， 防 止 向 错误 的 线程 发 送信 号 。 进 程 ID 












































或 线程 ID 这 种 资源 是 由 内 核 负 责 管 理 的， 进程 《或 线程 ) 有 自己 的 生命 周期 ， 比 如 向 线程 耳 为 1234 的 线程 发 送信 号 时 ， 很 可 能 线程 1234 早 就 退 
出 了 ， 而 线程 ID 1234 恰 好 被 内 核 分 配给 了 男 一 个 不 相干 的 进程 。 这 种 情况 下 ， 如 果 直 接 调用 tkill， 就 会 将 信号 发 送 到 不 相干 的 进程 上 。 为 了 防 
止 出 现 这 种 情况 ， 于 是 内 核 引 入 了 tekill 系 统 调用 ， 含 义 是 向 线程 组 ID 是 tgid、 线 程 ID 为 tid 的 线程 发 送信 号 。 这 样 ， 出 现 误杀 的 可 能 就 几乎 不 存在 
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这 两 个 函数 都 是 Linux 特 有 的 ， 存 在 可 移植 性 的 问题 。 


























6.8.2 raise 函 数 


Linux 提 供 了 疝 进程 自身 发 送信 号 的 接口 : raise 函 数 ， 其 定义 如 下 : 





#include <signal.h> 
int raise(int sig); 





这 个 接口 对 于 单线 程 的 程序 而 言 ， 就 相当 于 执行 如 下 语句 : 





kill (getpid(),sig) 





这 个 接口 对 于 多 线程 的 程序 而 言 ， 就 相当 于 执行 如 下 语句 : 





pthread kill (pthread self(),sig) 





执行 成 功 的 时 候 ， 返 回 0， 和 否则 返回 非 零 的 值 ， 并 置 errno。 如 果 sig 的 值 是 无 效 的 ，raise 函 数 就 将 
errno 置 为 EINVAL。 














值得 注意 的 是 ， 信 和 号 处 理 函 数 执行 完毕 之 后 ，raise 才 能 返回 。 


6.8.3 ”sigqueue 函 数 


在 信号 发 送 的 方式 当中 ，sigqueue 算 是 后 起 之 秀 ， 传 统 的 信号 多 月 
为 signal 函 数 的 表达 力 有 限 ， 控 制 不 够 精 # 
的 发 送 。 当 然 了 ，sigqueue 函 数 也 能 发 送 非 实时 信号 。 





六 























sigqueue 函 数 的 接口 定义 如 下 : 














日 signal/kill 这 两 个 函数 搭配 ， 完 成 信号 处 理 函 数 的 安装 和 信和 号 的 发 送 。 后 来 
































让， 所 以 引入 了 sigaction 函 数 来 负责 信号 的 安装 ， 与 其 对 应 的 是 ， 引 入 了 sigqueue 函 数 来 完成 实时 信和 号 





#include <signal.h> 


int sigqueue (Pid t pid, int sig, const union sigval value); 


























sigqueue 函 数 拥 有 和 kill 函 数 类 似 的 语义 ， 也 可 以 发 送 空 信号 (信号 0) 来 检查 进程 是 否 存在 。 和 kill 函 数 不 同 的 地 方 在 于 ， 它 不 能 通过 将 pid 














指定 为 负 值 而 向 整个 进程 组 发 送信 号 。 

















比较 有 意思 的 是 函数 的 第 三 个 入 参 ， 





下 : 


它 指 定 了 信号 的 伴随 数据 (或 者 称 为 

















了 效 载荷 ，payload) ， 该 参数 的 数据 类 型 是 联合 体 ， 定 义 代 码 如 





union sigval { 
int sival int; 
void *sival ptr; 


过 






































进程 几乎 没 





uy 




















© 注意 “尽管 跨 进程 使 

















sigval 中 的 指针 sival_ ptr 没有 介 
函数 中 ， 如 POSIX 计 时 器 的 tmer create 函数 和 POSIX 消 息 队 列 吕 


























通过 指定 sigqueue 函 数 的 第 三 个 参数 ， 可 以 传递 一 个 int 值 或 指针 给 目标 进程 。 考 虑 到 不 同 的 进程 有 各 自 独立 的 地 址 空间 ， 传 递 指针 到 另 一 个 
乎 没有 任何 意义 。 因 此 sigqueue 函 数 很 少 传递 指针 (sival_ptr) ， 大 多 是 传递 整 型 〈sival int) 。 


























F 何 意义 ， 但 sival_ptr 字 段 并 非 百 无 一 用 。 该 字段 可 用 于 使 用 sigval 联 合体 的 其 他 
的 mq_notify 函 数 。 





























sigval 联 合体 的 存在 ， 扩 展 了 信号 的 通信 和 能力。 
为 不 同 的 int 值 ， 通 过 sigval 联 合体 ， 将 事件 发 送 给 目 
传递 的 消息 内 容 受 到 了 限制 ， 不 容易 扩 


























很 ， 






























































所 以 不 宜 作 为 常规 的 通信 手段 。 





























下 面 的 例子 会 使 用 sigqueue 函 数 向 目 























标 进程 发 送信 号 ， 其 中 








些 简单 的 消息 传递 完全 可 以 使 用 sigqueue 函 数 来 进行 。 比 如 ， 通 信 双 方 事先 定义 菜 些 事 件 
标 进 程 。 目 标 进程 根据 联合 体 中 的 int 值 来 区 分 不 同 的 事件 ， 做 出 不 同 的 响应 。 但 是 这 种 方法 
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标 进 程 、 信 号 值 和 发 送 次 数 都 可 指定 ， 发 送信 号 的 同时 ， 也 发 送 了 伴随 数据 。 








#include <signal.h> 
#include <sys/types.h> 
#include <unistd.h> 
#include <string.h> 
#include <errno.h> 
#include <stdio.h> 
#include <stdlib.h> 
void usage () 


fprintf (stderr, "sigqueue send sig pid [times]Nn") 


} 
int main(int argc,char* argv[]) 
4 
pid t pid; 
int. sig} 
int times = 0; 
union sigval mysigval »; 
i (arge < 3} 
: 
usage (); 
return -1; 
pid = atoi (argv[1]); 
sig = atoi (argv[2]); 
if(argc >= 4) 
{ 
times = atoi (argv[3]); 
} 
mysigval.sival int = 123; 


if(sig < 0 || sig >64 ||times < 0) 


: 
usage (); 
return -2; 

上 

int i 

Eee 过 


f 


0 
0 ; i< times; I++) 


if (sigqueue (pid, sig,mysigval) 


{ 


!= 0) 


fprintf (stderr,"sigqueue failed (%s)\n", strerror (errno)); 


return -3; 
} 
} 


return 0; 





一 般 来 说 ，sigqueue 函 数 的 黄金 搭档 是 sigaction 函 数 。 在 使 























所 





jsigaction 函 数 时 ， 只 要 给 成 员 变量 sa_flags 置 上 SA_SIGINFO 的 标志 位 ， 就 可 以 使 

















三 参数 的 信号 处 理 函 数 来 处 理 实时 信号。 

















struct sigaction act: 


act.sa flags |= SA SIGINFO; 











三 参数 的 信号 处 理 函数 如 下 : 





void handle (int, siginfo t *info, void *ucontext); 





siginfo_t 结 构 体 存在 以 下 成 员 : 








siginfo 七 { 


i si signo; 

int si errno; 

int si code; 

int si trapno; 
汉 寺 堵 si pid; 

uid 七 si uid; 
union sigval si value; 
void *si_addr 


























这 个 结构 体 包含 很 多 信息 ， 目 标 进 程 可 以 通过 该 数据 结构 获取 到 如 下 的 信息 : 




















“si_signo: 信号 的 值 。 




















si_code: 信号 来 源 ， 可 以 通过 这 个 值 来 判断 信号 的 来 源 ， 上 基体 见 表 6-13。 








表 6-13 ”si_code 的 值 及 其 含义 


si_code 信号 来 源 
SI USER 调用 kill 或 raise 的 用 户 进程 
SI TKILL 调用 tkill 或 tgkill 的 用 户 进 程 
SI_QUEUE 调用 sigqueue 函数 的 用 户 进程 
SI MESGQ 消息 到 达 POSIX 消息 队列 
SI KERNEL 内 核 产生 的 信号 
SI ASYNCIO 异步 IO 操作 完成 
SI TIMER POSIX 定时 需 到 期 











除 此 之 外 ， 一 些 特殊 的 信号 会 产生 一 些 独特 的 si_code， 来 表示 信号 产生 的 根源 或 来 源 。 




















例如 ， 如 果 无 效 地 址 对 齐 引 发 SIGBUS 信 号 ，si_code 就 会 被 置 为 BUS ADRALN 等 。 想 进一步 了 解 详情 ， 可 以 查看 glibc 的 bits/siginfo.h 头 文 











'Si_value: sigqueue 函 数 发 送信 号 时 所 带 的 伴随 数据 。 














“si_pid: 信号 发 送 进程 的 进程 ID 。 


























si_uid: 信和 号 发 送 进程 的 真实 用 户 ID。 














'si_addr: 仅 针对 硬件 产生 的 信号 SIGBUS、SIGFPE、SIGILL 和 SIGSEGV 设 置 该 字段 ， 该 字段 表示 无 效 的 内 存 地 址 (SIGBUS 和 SIGSEGV) 或 
导致 信号 产生 的 程序 的 指令 地 址 〈SIGFPE 和 SIGILL) 。 














三 参数 信号 处 理 函 数 的 第 三 个 参数 是 void* 类 型 的 ， 其 实 它 是 一 个 ucontext t 类 型 的 变量 。 











typedef struct ucontext 

{ 
unsigned long int uc flags; 
struct ucontext *uc link; 


Stack t uc stack; 


mcontext t uc mcontext; 
_ sigset t uc sigmask; 
struct libc fpstate _ fpregs mem; 


} ucontext t; 





























这 个 结构 体 提供 了 进程 上 下 文 的 信息 ， 用 于 描述 进程 执行 信号 处 理 函 























量 ， 但 是 该 变量 也 有 很 精妙 的 应 用 ， 如 下 面 的 例子 。 



































对 于 C 程 序 员 而 言 ， 基 本 4 
统 会 发 送 一 个 SIGSEGV 信 
的 信息 ， 然 后 再 优雅 地 退 











每 个 人 者 


B 呢 ? 可 以 通 

































































数 之 前 进程 所 处 的 状态 。 通 常情 况 下 信和 号 处 理 函 数 很 少 会 用 到 这 个 变 








t 





会 遇 到 段 错误 。 一 般 情 况 下 ， 段 错误 出 现 的 原因 是 程序 访问 了 非法 的 内 存 地 址 。 当 段 错误 发 生 时 ， 操 作 系 
号 给 进程 ， 导 致 进程 产生 核心 转 储 文件 并 且 退 出 






























































。 如 何 才 能 让 进程 先 捕捉 SIGSEGV 信 号 ， 打 印章 


让 
到 
过 





便 定 位 问题 








过 给 SIGSEGV 注 册 信 号 处 理 函 数 来 





实现 ， 代 码 如 下 所 示 : 





#ifndef GNU _ SOURCE 
#define _GNU SOURCE 
#endif 

#ifndef USE GNU 
#define _ USE GNU 
#endif 
#include <execinfo.h> 
#include <signal.h> 
#include <stdio.h> 
#include <stdlib.h> 
#include <string.h> 
#include <ucontext.h> 
#include <unistd.h> 





typedef struct sig ucontext { 
ng uc flags; 
wuc link; 
uc stack; 


unsigned long 
struct ucontext 
stack t 
struct sigcontext 
sigset t 

} sig ucontext 七 ? 


uc mcontext; 
uc sigmask; 


void crit err hdlr(int sig num, siginfo t * info, void * ucontext) 


{ 
void * 
void * 
char 站 
int 
sig ucontext 七 * 


array[50]; 


caller address; 


messages; 


size, i; 


uc; 


uc = (sig ucontext t *)ucontext; 


caller address = 


(void *) uc->uc mcontext.rip; 


fprintf (stderr, "signal %d (%s), address is %p from %p\n", 
sig num, strsignal (sig num), info->si addr, 
(void *)caller address); 
size = backtrace (array, 50); 
array[1] = caller address; 
messages = backtrace symbols (array, size); 


/* 跳 过 第 一 个 栈 帧 


Wy 


for (i = 1; i < size && messages != NULL; ++i) 


fprintf (stderr, 


} 


free (messages); 


exit (EXIT FAILURE); 


int crash () 
char * p = NULL; 
xp = 0; 
return 0; 


int foo4() 


crash (); 
return 0; 


int foo3() 


foo4(); 
return 0; 


int foo2 () 


foo3 () 
return 0; 


int fool() 


foo2 () 
return 0; 


"[bt]: (%d) 


int main(int argc, char xx argv) 


struct sigaction sigact; 
sigact.sa sigaction 


sigact.sa flags = 


if (sigaction (SIGSEGV, &sigact, 


{ 


fprintf (stderr, 


SIGSEGV， 


Ss\n", i, messages[i]); 


= Crit err hdlr; 
SA RESTART | SA SIGINFO; 
(struct sigaction *)NULL) != 0) 


"error setting signal handler for %d ($s)\n", 


exit (EXIT FAILURE); 


+. 
fool(); 
exit (EXIT_ SUCCESS) 


; 


strsignal (SIGSEGV) ) ， 





























上 面 的 函数 利用 了 
印 出 来 ， 输 出 如 下 : 


























第 三 个 参数 里 本 




















的 ucontext->uc_mcontext.rip 字 段 ， 专 























A 取 到 了 收 到 信号 前 的 EIP 寄 存 器 的 值 ， 根 据 该 值 ， 可 以 将 堆栈 信息 打 








manu@manu-hacks:~/code/me/aple/chapter 05$ ./print bt 
signal 11 (Segmentation fault), address is (nil) from 0x40089d 


Wtls (ly /peint Bt ty 
[bt]s (2) sprint bt{) 
Wil (3 » print st} 
[Et (4 /print bt{) 


[0x40089d] 
[Ox40089d] 
[0x4008b5] 
[0x4008cal] 


(5) ./print bt() [0x4008df 

: (6) ./print bt() [0x4008f4 
[bt]: (7) ./print bt() [0x400984 
(8) /lib/x86 64-linux-gnu/libc.so.6( libc start main+0xf5) [0x7f6a8fa88ec5] 

(9) ./print bt() [0x400679 









































nD 





























缺点 是 没有 打印 出 函数 名 ， 只 打印 了 指令 的 地 址 。 我 们 固然 可 以 使 用 objdump 得 到 汇编 文件 ， 根 据 地 址 查找 到 各 自 的 函数 名 ， 但 是 了 
太 多 ， 效 率 太 低 。 如 果 在 编译 的 时 候 ， 带 上 -rdynamic 选 项 ， 就 可 打印 出 函数 的 地 址 了 ， 代 码 如 下 所 示 : 


























root@manu-hacks:~/code/c/self/signal# gcc -o print bt print core.c -rdynamic 
manu@manu-hacks:~/code/me/aple/chapter 05$ ./print bt 

signal 11 (Segmentation fault), address is (nil) from 0x400c0d 

[bt]: (1) ./print bt(crash+0x10) [0x400c0d] 


[bt]: (2) ./print bt (crash+0x10) [0x400c0d] 
[bt]: (3) ./print bt (foo4+0xe) [0x400c25] 
[bE] 0x400c3a] 


( 
( ( 
( ( 
(4) ./print bt (foo3+0xe) [ 
[bt]: (5) ./print bt (foo2+0xe) [0x400c4f] 
( ( [ 
( 
( 
( 


[eT BY /print bt fool+0xe) [0x400c64] 

[bt]: (7) ./print bt (main+0x89) [0x400cf4] 

[bt]: (8) /lib/x86 64-linux-gnu/libc.so.6( libc start main+0xf5) [0x7efe7d126ec5] 
[bt]: (9) ./print bt() [0x4009e9] 
































这 样 就 可 以 很 清楚 地 看 到 堆栈 调用 的 关系 ， 方 便 进一步 定位 问题 。 











6.9 ”信号 与 线程 的 关系 





前 面 也 曾 简单 提 到 过 多 线程 ， 比 如 如 何 向 多 线程 中 的 某 个 线程 发 送信 号 ， 本 节 就 来 重点 讲述 多 线 
程 与 信号 的 关系 。 








提 到 线程 与 信号 的 关系 ， 必 须 先 介 绍 下 POSIX 标 准 ，POSIX 标 准 对 多 线程 情况 下 的 信号 机 制 提 出 了 




















.信号 处 理 函 数 必须 在 多 线程 进程 的 所 有 线程 之 间 共 享 ， 但 是 每 个 线程 要 有 自己 的 挂 起 信号 集合 和 
阻塞 信号 掩 码 。 











POSIX 函数 kill/sigqueue 必 须 面向 进程 ， 而 不 是 进程 下 的 某 个 特定 的 线程 。 











` 每 个 发 给 多 线程 应 用 的 信号 仅 递送 给 一 个 线程 ， 这 个 线程 是 由 内 核 从 不 会 阻塞 该 信号 的 线程 中 随 
意 选 出 来 的 。 





如果 发 送 一 个 致命 信号 到 多 线程 ， 那 么 内 核 将 杀 有 死 该 应 用 的 所 有 线程 ， 而 不 仅仅 是 接收 信号 的 那 


个 线程 。 











这 些 就 是 POSIX 标 准 提出 的 要 求 ，Linux 也 要 遵循 这 些 要 求 ， 那 它 是 怎么 做 到 的 呢 ? 


6.9.1 ”线程 之 间 共 享 信号 处 理 函 数 


























对 于 进程 下 的 多 个 线程 来 说 ， 信 和 号 处 理 函 数 是 共享 的 。 
























































在 Linux 内 核实 现 中 ， 同 一 个 线程 组 里 的 所 有 线程 都 共享 一 个 struct sighand 结 构 体 。 该 结构 体 中 存在 一 个 action 数 组 ， 数 组 
64 项 ， 每 一 个 成 员 都 是 k_sigaction 结 构 体 类 型 ， 一 个 k_sigaction 结 构 体 对 应 一 个 信号 的 信号 处 理 函 数 。 














相关 数据 结构 定义 如 下 《这 与 架构 相关 ， 这 里 给 出 的 是 x86 64 位 下 的 定义 ) : 





struct sigaction { sighandler t sa handler; 
unsigned long sa flags; 
_ Sigrestore 七 sa restorer; 
Sigset t sa mask; 


struct k sigaction { 
struct sigaction sa; 
}; 
struct sighand struct { 
atomic t count; 
struct k sigaction action[_ NSIG]; 
spinlock t siglock; 
wait queue head t signalfd waqh; 


}; 
struct task struct{ 


struct sighand struct *sighand;... 





多 线程 的 进程 中 ， 信 号 处 理 函 数 相关 的 数据 结构 如 图 6-2 所 示 。 

















内 核 中 k sigaction 结 构 体 的 定义 和 8glibc 中 sigaction 函 数 中 用 到 的 struct sigaction 结 构 体 的 定义 几乎 是 一 样 的 。 通 过 sigaction 函 
数 安装 信号 处 理 函 数 ， 最 终 会 影响 到 进程 描述 符 中 的 sighand 指 针 指 向 的 sighand_struct 结 构 体 对 应 位 置 上 的 action 成 员 变 量 


有 Eo 






































在 创建 线程 时 ， 最 终 会 执行 内 核 的 do_fbrk 函 数 ， 由 do_fork 函 数 走 进 copy sighand 来 实现 线程 组 内 信和 号 处 理 函 数 的 共享 。 创 
建 线 程 时 ，CLONE SIGHAND 标 志 位 是 置 位 的 。 创 建 线 程 组 的 主线 程 时 ， 内 核 会 分 配 sighand_struct 结 构 体 ， 创 建 线程 组 内 的 其 
他 线程 时 ， 并 不 会 另起炉灶 ， 而 是 共享 主线 程 的 sighand_struct 结 构 体 ， 只 须 增 加 引用 计数 而 已 。 









































线程 1 task struct 







structlsloghandestruet 


action[63] 


图 6-2 ”同一 进程 里 的 多 个 线程 共享 信号 处 理 函 数 


Stzucb Kk SIgaction 







































































static int copy sighand(unsigned long clone flags, 
struct task struct *tsk) 
{ 


struct sighand struct *sig; 
if (clone flags & CLONE SIGHAND) { 
/ /如 果 发 现 是 线程 ， 则 直接 将 引用 计数 


十 十 ， 无 须 分 配 


Sighand struct 结 构 


atomic inc(&current->sighand->count); 
return 0; 
} 
sig = kmem cache alloc(sighand cachep, GFP KERNEL); 
rcu assign pointer (tsk->sighangd, sig); 
i (tai) 
return -ENOMEM; 
atomic set (&sig->count, 1); 
memcpy (sig->action, current->sighand->action, sizeof (sig->action)); 


return 0; 








6.9.2 ”线程 有 独立 的 阻塞 信号 捧 码 














首先 需要 介绍 什么 是 阻塞 信号 掩 码 。 


一 | 








每 个 线程 都 拥有 独立 的 阻塞 信号 掩 码 。 在 介绍 这 条 性 质 之 衣 



























































重要 会 议 时 要 关闭 手机 一 样 ， 进 程 在 执行 某 些 重要 操作 时 ， 不 希望 内 核 递 送 某 些 信号 ， 阻 塞 信号 掩 码 就 是 用 来 实现 该 功能 的 。 
乔 码 ， 纵 然 内 核 收 到 了 该 信号 ， 甚 至 该 信号 在 挂 起 队列 中 己 经 存在 了 相当 长 的 时 间 ， 内 核 也 不 会 将 信号 递 











就 像 我 们 
如 果 进 程 将 某 信号 添加 进 了 阻塞 信号 
送 给 进程 ， 直 到 进程 解除 对 该 信号 的 阻塞 为 止 。 













































































EE 要 的 电话 ， 比 如 儿子 老师 的 电话 、 父 母 的 电 
部 分 信号 ， 而 不 是 所 有 信号 。 








[el 
Wh 



































会 时 关闭 手机 是 一 种 比较 极端 的 例子 。 更 合理 的 做 法 是 暂时 屏蔽 部 分 人 的 电话 。 对 于 某 些 
话 或 老板 的 电话 ， 是 不 希望 被 屏蔽 的 。 信 和 号 也 是 如 此 。 进 程 在 执行 某 些 操作 的 时 候 ， 可 能 只 需要 屏蔽 





















































数据 类 型 为 sigset t。 在 Linux 的 实现 








TI 











为 了 实现 掩 码 的 功能 ，Linux 提 供 了 一 种 新 的 数据 结构 :信号 集 。 多 个 信号 组 成 的 集合 被 称 为 信号 集 ， 
中 ，sigset t 的 类 型 是 位 掩 码 ， 每 一 个 比特 代表 一 个 信号 。 

















mE 


号 集 ， 如 下 : 





Linux 提 供 了 两 个 函数 来 初始 化 





#include<signal.h> 
int sigemptyset (sigset t *set); 
int sigfillset (sigset t *set); 



































sigemptyset 函 数 用 来 初始 化 一 个 空 的 未 包含 任何 信号 的 信号 集 ， 而 sigfillset 函 数 则 会 初始 化 一 个 包含 所 有 信和 号 的 信号 集 。 

















» 




















© 注意 ”必须 要 调用 这 两 个 初始 化 函数 中 的 一 个 来 初始 化 信号 集 ， 对 于 声明 了 sigset t 类 型 的 变量 ， 不 能 一 厢 情 愿 地 假设 它 是 空 集 
也 不 能 调用 memset 函 数 ， 或 者 用 赋值 为 0 的 方式 来 初始 化 。 






























































初始 化 信号 之 后 ，Linux 提 供 了 sigaddset 函 数 向 信号 集中 添加 一 个 信号 ， 同 时 还 提供 了 sigdelset 函 数 在 信号 集中 移 除 一 个 信号 





int sigaddset (sigset t *set, int signum); 
int sigdelset (sigset t *set, int signum); 








为 了 判断 某 一 个 信号 是 否 属于 信和 号 集 ，Linux 提 供 了 sigismember 函 数 : 








int sigismember (const sigset t *set, int signum); 























如 果 signum 属 于 信号 集 ， 则 返回 1， 和 否则 返回 0。 出 错 的 时 候 ， 返 回 -1。 






























































写 掩 码 了 。Linux 提 供 了 sigprocmask 函 数 来 做 这 件 事情 : 














有 了 信号 集 ， 就 可 以 使 用 信号 集 来 设置 进程 的 阻塞 信 




















#include <signal.h> 
int sigprocmask (int how, const sigset t *set, sigset t *oldset); 





























sigprocmask 根 据 how 的 值 ， 提 供 了 三 种 用 于 改变 进程 的 阻塞 信号 掩 码 的 方式 ， 见 表 6-14。 





表 6-14 ”sigprocmask 函 数 中 how 的 含义 


how 参数 全 义 
新 的 县 当前 售 码 与 set 指向 信和 号 集 的 并 集 ， 当 于 在 当前 信号 拖 三 
SIG BLOCK 新 的 进程 言 号 拖 码 是 当前 信和 号 拖 码 与 set 指向 信号 集 的 并 集 ， 相 当 于 在 当前 信和 号 掩 码 中 
增加 set 中 的 信和 号 
新 的 进程 信号 抢 码 是 当前 信号 掩 码 与 set 指 回 信号 集 的 补 集 的 交集 ， 相 当 于 从 当前 信号 


5 人 3 | 掩 码 中 删除 set 中 的 信号 ， 解 除 对 其 的 屏蔽 


SIG SETMASK 直接 把 进程 的 信和 号 掩 码 设 图 成 set 指向 的 信号 集 




















© 我 们 知道 SIGKILL 信 号 和 SIGSTOP 信 和 号 不 能 阻塞 ， 可 是 如 果 调 用 sigprocmask 函 数 时 ， 将 SIGKILL 信 号 和 SIGSTOP 信 和 号 添加 进 阻 








了 
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o 











TI 








昌 塞 信号 外 








本 | 


sigprocmask 函 数 不 会 报错 ， 但 是 也 不 会 将 SIGKILL 和 SIGSTOP 真 的 添加 进 





答案 是 不 怎么 样 。 





月 会 执行 如 下 语句 ， 剔 除 掉 集 合 中 的 SIGKILL 和 SIGSTOP: 





对 应 的 rt_sigprocmask 系 统 调 月 





Sigdelsetmask (&new_ set, sigmask (SIGKILL) |sigmask (SIGSTOP)); 








个 线程 都 有 自己 的 阻塞 信号 


























对 于 多 线程 的 进程 而 言 ， 每 








struct task struct{ 
sigset t blocked; 








它 出 现在 线程 尚未 引入 Linux 的 时 代 。 在 


则 用 线程 的 阻塞 信号 























程 。sigprocmask 出 现 得 比较 
































线程 的 阻塞 信号 掩 码 ， 而 不 是 整个 进 
的 阻塞 掩 码 是 一 回 事 ， 但 是 引入 多 线程 之 后 ，sigprocmask 的 语义 就 变 成 了 设置 














sigprocmask 函 数 改 变 的 是 调 
单线 程 的 时 代 ， 进 程 的 阻塞 信号 掩 码 和 线程 
掩 码 。 

为 了 更 显 式 地 设置 线程 的 阻 寨 信 号 掩 码 ， 线 程 请 























EF 提供 了 pthread_sigmask 函 数 来 设置 线程 的 阻塞 信号 掩 码 : 























#include <signal.h> 
int pthread sigmask(int how, const sigset t *set, sigset t *oldset); 





事实 上 pthread_sigmask 函 数 和 sigprocmask 函 数 的 行为 是 一 样 的 。 








6.9.3 ”私有 挂 起 信号 和 共享 挂 起 信号 






























































POSIX 标 准 中 有 如 下 要 求 : 对 于 多 线程 的 进程 ，kill 和 sigqueue 发 送 的 信号 必须 面 对 所 有 的 线程 ， 而 不 是 某 个 线程 ， 内 核 是 如 何 做 到 的 呢 ? 
而 系统 调用 tkill 和 tegkill 发 送 的 信号 ， 又 必须 递送 给 进程 下 某 个 特定 的 线程 。 内 核 又 是 如 何 做 到 的 呢 ? 
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前 面 简单 提 到 过 内 核 维护 有 挂 起 队列 ， 尚 未 递送 进程 的 信号 可 以 挂 入 挂 起 队列 中 。 有 意思 的 是 ， 内 核 的 进程 描述 符 task_struct 之 中 ， 维 护 了 
两 套 sigpending， 代 码 如 下 所 示 : 





struct task struct{ 


struct signal struct *signal; 
struct sighand struct *sighand; 
struct sigpending pending; 
} 
struct signal struct {,.. 
struct sigpending shared pending; 


} 








结构 如 图 6-3 所 示 。 











task struct sigqueue 


pending.1list 
pending.signal 




















signal struct 


shared pending. list 
shared pending.signal 








图 6-3 ”信号 挂 起 队列 相关 的 数据 结构 















































内 核 就 是 靠 这 两 个 挂 起 队列 实现 了 POSIX 标 准 的 要 求 。 在 Linux 实 现 中 ， 线 程 作为 独立 的 调度 实体 也 有 自己 的 进程 描述 符 。Linux 下 既 可 以 向 
进程 发 送信 号 ， 也 可 以 向 进程 中 的 特定 线程 发 送信 号 。 因 此 进程 描述 符 中 需要 有 两 套 sigpending 结 构 。 其 中 task _struct 结 构 体 中 的 pending， 记 录 




























































































的 是 发 送 给 线程 的 未 决 信号 ， 而 通过 signal 指 针 指 向 signal_struct 结 构 体 的 shared_pending， 记 录 的 是 发 送 给 进程 的 未 决 信号 。 每 个 线程 都 有 自己 
的 私有 挂 起 队列 〈pending) ， 但 是 进程 里 的 所 有 线程 都 会 共享 一 个 公有 的 挂 起 队列 〈shared pending) 。 




































































图 6-4 描 述 的 是 通过 kill、sigqueue、tkill 和 tegkill 发 送信 号 后 ， 内 核 的 相关 处 理 流 程 。 














(when pid>0) 
kill something info 了 Brno dnE6 


kill pid info do tkill 
group send sig info do send specific 


do send sig info 


__send signal 











图 6-4 ”发 送信 号 相关 的 内 核 处 理 流程 


























从 图 6-4 中 可 以 看 出 ， 向 进程 发 送信 号 也 好 ， 向 线程 发 送信 号 也 黑 
还 是 存在 不 同 。 不 同 的 地 方 在 于 ， 到 底 将 信号 放 入 哪个 挂 起 队列 。 





， 最 终 都 殊途同归 ， 在 do_send_sig info 函 数 处 会 师 。 尽 管 会 师 在 一 处 ， 却 






























































在 、send_signal 函 数 中 ， 通 过 group 入 参 的 值 来 判断 需要 将 信号 放 入 哪个 挂 起 队列 《如 果 需 要 进 队列 的 话 ) 。 


TH 





static int _send signal (int sig, struct siginfo *info struct task struct *t, 
int group, int from ancestor ns) 
' 


...Pending = group ? &t->signal->shared pending : 
} 


&t->pending;... 






































如 果 用 户 调用 的 是 kill 或 sigqueue， 那 么 group 就 是 1; 如 果 用 户 调 月 
给 进程 的 还 是 发 给 某 个 特定 线程 的 ， 如 表 6-15 所 示 。 

















目的 是 tkill 或 tgkill， 那 么 group 参 数 就 是 9。 内 核 就 是 以 此 来 区 分 该 信号 是 发 


表 6-15 各 种 发 送信 号 的 函数 与 信号 挂 起 队列 的 关系 
项 数 group 的 值 说 明 


kill/sigqueue | 需要 的 话 ， 将 信号 挂 入 多 个 线程 共享 的 signal->shared_pending 


tkill/tgkill 需要 的 话 ， 将 信号 挂 入 线程 私有 的 挂 起 队列 pending 



































上 述 情景 并 不 难 理解 。 多 线程 的 进程 就 像 是 一 个 班级 ， 进 程 下 的 每 一 个 线程 就 像 是 班级 的 成 员 。kill 和 sigqueue 函 数 发 送 的 信号 是 给 进程 
的 ， 就 像 是 优秀 班 集体 的 荣誉 是 颁发 给 整个 班级 的 ， 人 kill 和 tgkill 发 送 的 信号 是 给 特定 线程 的 荣 


言 号 是 ， 就 像 是 三 好 学 生 的 荣誉 是 颁发 给 学 生 个 人 的 。 






























































8? 这 个 问题 就 和 高 二 《五 ) 班 荣获 优秀 班 集体 ， 


人 

















男 一 个 需要 解决 的 问题 是 ， 多 线程 情况 下 发 送 给 进程 的 信号 ， 到 底 由 哪个 线程 来 负责 处 型 
负责 上 人 台 , 


























内 核 是 不 是 一 定 会 将 信号 递送 给 进程 的 主线 程 ? 























答案 是 不 一 定 。 尽 管 如 此 ，Linux 还 是 采取 了 尽力 而 为 的 策略 ， 尽 量 地 尊重 函数 调用 者 的 意愿 ， 如 果 进 程 的 主线 程 方便 的 话 ， 则 优先 选择 主 
线程 来 处 理 信号 ;如果 主线 程 确实 不 方便 ， 那 就 有 可 能 由 线程 组 里 的 其 他 线程 来 负责 处 理 信 号 。 











































































































用 户 在 调用 kill/sigqueue 函 数 之 后 ， 内 核 最 终 会 走 到 _send_signal 函 数 。 在 该 函数 的 最 后 ，! 











complete_signal 函 数 负责 寻找 合适 的 线程 来 处 理 
该 信号 。 因 为 主线 程 的 线程 ID 等 于 进程 ID， 上 所 以 该 函数 会 优先 查询 进程 的 主线 程 是 否 方便 处 理 信 号 。 如 果 主 线程 不 方便 ， 则 会 遍历 线程 组 中 的 
其 他 线程 。 如 果 找 到 了 方便 处 理 信号 的 线程 ， 就 调 / 






















































































jsignal wake_ up 函数 ， 唤 醒 该 线程 去 处 理 信和 号。 





signal wake up(t, sig == SIGKILL) 











如 果 线 程 组 内 全 都 不 方便 处 理 信 号 ，complete 函 数 也 就 当即 返回 了 。 


























如 何 判断 方便 不 方便 ? 内 核 通过 wants_signal 函 数 来 判断 某 个 调度 实体 是 否 方便 处 理 某 信和 号: 








static inline int wants signal (int sig, struct task struct *p) 
{ 
if (sigismember (&p->blocked，sig))/* 位 于 阻塞 信号 集 ， 不 方便 


wy 
return 0; 
if (p->flags & PF _EXITING) /* 正 在 退出 ,不 方便 
wy 
return 0; 
if (sig == SIGKILL) /*SIGKILL 信 号 ,必须 处 理 
和 
return 1; 
if (task is_stopped or traced (P) ) /* 被 调试 或 被 暂停 ， 不 方便 
Ry 


return 0; 
return task curr(p) || !signal pending (p); 














长 

















glibc 提 供 了 一 个 API 来 获取 当前 线程 的 阻塞 挂 起 信号 ， 如 下 : 





#include <signal.h> 
int sigpending (sigset t *set); 




















该 函数 很 容易 产生 误解 ， 很 多 人 认为 该 接口 返回 的 是 线程 的 挂 起 信号 ， 即 还 没有 来 得 及 处 理 的 信号 ， 这 种 理解 其 














实 是 错误 的 。 
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IT 





严格 来 讲 ， 返 





的 信号 集中 的 信号 必须 同时 满足 以 下 两 个 条 件 : 














:处 于 挂 起 状态 。 








“信号 属于 线程 的 阻塞 信号 


注 
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看 下 内 核 的 do_sigpending 函 数 的 内 容 就 不 难 理解 sigpending 函 数 的 含义 了 : 











Spin _ lock irq(&current->sighand->siglock); 
sigorsets (&pendqing，&current->pending.signal， 
&current->signal->shared pending.signal); 

spin unlock irq(&current->sighand->siglock); 
sigandsets (gpending, &current->blocked, &pending); 
error = -EFAULT; 

if (!copy to userl(set, &pending, sigsetsize)) 

erpor = UO: 











此 ， 返 
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的 挂 起 阻塞 信号 集合 的 计算 方式 是 : 


























1) 进程 共享 的 挂 起 信号 和 线程 私有 的 挂 起 信号 取 并 集 ， 得 到 集合 1。 









































1 








2) 对 集合 1 和 线程 的 阻塞 信号 集 取 交集 ， 以 获得 最 终 的 结果 。 





从 此 处 可 以 看 出 ，sigprocmask 函 数 会 影响 到 sigpendig 函 数 的 输出 结果 。 





6.9.4 致命 信号 下 ， 进 程 组 全 体 退 出 


关于 进程 的 退出 ， 前 面 已 经 有 所 提 及 ，Linux 为 了 应 对 多 线程 ， 提 供 了 exit _ group 系统 调用 ， 确 保 多 
个 线程 一 起 退出 。 对 于 线程 收 到 致命 信号 的 这 种 情况 ， 操 作 是 类 似 的 。 可 以 通过 给 每 个 调度 实体 的 
pending 上 挂 上 一 个 SIGKILL 信 号 以 确保 每 个 线程 都 会 退出 。 此 处 就 不 再 次 述 了 。 











6.10 等待 信和 号 


有 时 候 ， 需 要 等 待 某 种 信号 的 发 生 。POSIX 中 的 pause、sigsuspend 和 sigwait 函 数 提供 了 三 种 方法 ， 
可 以 将 进程 暂时 挂 起 ， 等 待 信号 来 临 。 





6.10.1 pause 函数 









































pause 函 数 将 调用 线程 挂 起 ， 使 进程 进入 可 中 断 的 睡眠 状态 ， 直 到 传递 了 一 个 信号 为 止 。 这 个 信号 的 动作 或 者 是 执行 用 户 定义 的 信号 处 理 函 
数 ， 或 者 是 终止 进程 。 如 果 是 执行 用 户 自 定义 的 信号 处 理 函 数 ， 那 么 pause 会 在 信号 处 理 函 数 执行 完毕 后 返回 ， 如 果 是 终止 进程 ，pause 函 数 就 不 
返回 了 。 如 果 内 核发 出 的 信号 被 忽略 ， 那 么 进程 就 不 会 被 唤醒 。 
































































































































pause 函 数 的 定义 如 下 : 





#include <unistd.h> 
int pause (void); 
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， 那 它 总 是 返 


I 





比较 有 意思 的 是 ，pause 函 数 如 果 可 以 返 -1， 并 且 errno 为 EINTR。 









































如 果 希 望 pause 函 数 等 待 某 个 特定 的 信号 ， 就 必须 确定 哪个 信号 会 让 pause 返 回 。 
在 等 待 的 信和 号， 我们 必须 间接 地 完成 这 个 任务 。 


事实 上 ，pause 并 不 能 主动 区 分 使 pause 返 回 的 信号 是 不 是 正 
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ul 









































常用 的 方法 是 ， 在 期 待 的 特定 信号 的 信号 处 理 函数 中 ， 将 某 变 量 的 值 设 置 为 1， 待 pause 返 回 后 ， 通 过 查看 该 变量 的 值 是 否 为 1] 来 判定 等 待 的 
特定 信号 是 否 被 捕获 ， 方 法 如 下 面 的 代码 所 示 : 




































































static volatile sig atomic t sig received flag = 0; 
while(sig received flag == 0) 
pause (); 


























如 果 只 有 等 待 的 那个 信号 的 处 理 函 数 会 将 sig_ received _flag 置 成 1， 那 么 进程 就 会 一 直 阻 塞 ， 直 到 接收 到 特定 的 信号 为 止 。 













































































看 起 来 很 美好 ， 可 是 上 面 的 逻辑 是 有 漏洞 的 。 检 查 sig_received_flag 一 0 和 调用 pause 之 间 存 在 一 个 时 间 窗 口 ， 如 果 在 该 时 间 窗 口内 收 到 信 
号 ， 并 且 信 和 号 处 理 函 数 将 sig received_fag 置 1， 那 么 主 控制 流 根本 就 不 知道 这 件 事 情 ， 进 程 就 会 依然 阻塞 。 也 就 是 说 ， 等 待 的 信号 已 经 到 来 ， 但 
是 进程 错过 了 。 在 收 到 下 一 个 信号 之 前 ，pause 函 数 不 会 返回 ， 进 程 也 就 没有 机 会 发 现 其 实在 等 待 的 信号 早 就 已 经 收 到 了 。 


















































































































































六 | 

















为 检查 和 pause 之 间 存 在 时 间 窗 口 ， 所 以 就 有 了 错失 信号 的 情况 ， 如 表 6-16 所 示 。 
































表 6-16 错失 等 待 信号 的 时 序 条 件 





0 | . 歼 | sig recelved flag == 0 
| 























下 面 通过 另 一 个 例子 来 描述 一 下 pause 的 困境 。 程 序 执行 过 程 中 ， 关 键 部 分 不 期 望 被 信号 打 断 ， 于 是 临时 阻塞 信号 ， 关 键 部 分 完成 之 后 ， 就 
解除 信号 的 阻塞 ， 然 后 暂停 执行 直到 有 信和 号 到 达 为 止 ; 






























































/* 关 键 代码 结束 


wy 
sigprocmask (SIG SETMASK, &orig mask,NULL); 
/* 此 处 信号 可 能 已 经 递送 给 进程 了 ， 导 致 


Pause 无 法 返回 


pause () 7 






































可 以 看 到 解除 对 特定 信号 的 阻塞 之 后 ， 调 用 pause 之 前 ， 信 和 号 已 经 被 递送 给 进程 ， 这 个 信号 已 经 错失 了 ，pause 无 法 等 到 这 个 信号 ， 直 到 下 
个 信号 递送 给 进程 为 止 ，pause 函 数 都 无 法 返回 。 这 就 违背 了 代码 的 本 意 : 解除 对 信号 的 阻塞 并 且 等 待 该 信号 的 第 一 次 出 现 。 




















到 






































要 避免 这 种 情况 ， 必 须 将 解除 信号 阻塞 和 挂 起 进程 等 待 信号 这 两 个 动作 封装 成 一 个 原子 操作 。 这 就 是 引入 sigsuspend 系 统 调用 的 原因 。 














6.10.2 sigsuspend 函 数 


在 pause 之 前 传递 信号 是 Linux 早 期 遇 到 的 一 个 困境 ， 并 没有 好 办 法 来 解决 这 个 问题 。 从 本 质 上 讲 ， 
必须 将 解除 对 信和 号 的 阻塞 和 挂 起 进程 以 等 待 信号 的 形式 封装 成 一 个 原子 操作 ， 才 能 解决 该 问题 ， 而 
sigsuspend 函 数 就 是 为 了 解决 这 个 难题 而 生 的 。 


sigsuspend 函 数 的 定义 如 下 : 





#include <signal.h> 
int sigsuspend(const sigset t *mask); 





如 果 信 号 终止 了 进程 ， 那 么 sigsuspend 函 数 不 会 返回 。 如 果 内 核 将 信号 递送 给 进程 ， 并 执行 了 信和 号 
处 理 函 数 ， 那 么 sigsuspend 函 数 返回 -1， 并 置 errno 为 EINTR。 如 果 mask 指 针 指向 的 地 址 不 是 合法 地 址 ， 
那么 sigsuspend 函 数 返 回 -1， 并 置 errno 为 EFAULT。 














sigsuspend 函 数 用 mask 指 向 的 掩 码 来 设置 进程 的 阻塞 掩 码 ， 并 将 进程 挂 起 ， 直 到 进程 捕捉 到 信号 为 
止 。 一旦 从 信号 处 理 函 数 中 返回 ，sigsuspend 函 数 就 会 把 进程 的 阻塞 掩 码 恢复 为 调用 之 前 的 老 的 阻塞 掩 
码 值 。 

















简单 地 说 ，sigsuspend 相 当 于 以 不 可 中 断 的 方式 执行 下 面 的 操作 : 





sigprocmask (SIG SETMASK, &mask, &old mask); 
pause (); 
sigprocmask (SIG SETMASK, &old mask,NULL); 








有 了 sigsuspend 消 数 ， 就 可 以 完成 上 一 节 pause 完 成 不 了 的 任务 了 。 





static volatile sig atomic t sig received flag = 0; 
sigset_ t mask all, mask 1 most, mask old; 

int signum = SIGUSR1; 

sigfillset (&mask all); 

sigfillset (&mask most); 
Sigdelset (gmask most,signum); 

sigprocmask (SIG SETMASK, gmask allv&mask old); 

/* 不 要 忘记 先 判 断 ， 因 为 在 


SigpFrocmask 阻 塞 所 有 信号 之 前 ， 


SIGUSR1 可 能 已 经 被 递送 


*/ 

if(sig received flag == 0) 
sigsuspend (&mask most); 

sigprocmask (SIG SETMASK, gmask old,NULL); 





假定 等 待 特定 信号 SIGUSR1， 首 先 要 将 所 有 的 信号 屏蔽 掉 ， 如 果 屏 项 信号 之 前 ， 已 经 收 到 了 





SIGUSR1， 那 么 sig received _ flag 会 被 设置 为 1， 此 时 就 不 需要 再 调用 sigsuspend 了 ， 我 们 已 经 等 到 了 要 等 
的 信号 SIGUSR1。 如 果 没 收 到 ， 则 调用 sigsuspend， 将 阻塞 掩 码 设 为 mask most， 即 将 所 有 信和 号 都 屏蔽 ， 
只 有 SIGUSR1 未 被 屏蔽 。sigsuspend 返 回 时 ， 我 们 就 可 以 确定 ， 收 到 了 信号 SIGUSR1。 此 时 ， 阻 塞 掩 码 
也 已 经 恢复 成 调用 sigsuspend 之 前 的 mask_all 了， 然后 显 式 地 将 阻塞 掩 码 恢复 成 默认 的 阻塞 掩 码 


mask old。 








等 一 等 ， 类 似 于 上 一 节 的 代码 ， 在 判断 之 后 、pause 之 前 ， 有 信号 递送 ， 会 导致 信号 错失 ， 那 么 在 
上 面 的 代码 中 ， 判 断 sig received flag==1 之 后 ， 调 用 sigsuspend 函 数 之 前 ， 是 否 会 有 SIGUSR1 被 递送 给 
进程 ， 再 次 导致 错失 信号 一 次 ? 答案 是 否定 的 ， 因 为 我 们 已 经 通过 setprocmask 函 数 阻 塞 了 所 有 的 信 
号 ， 因 此 SIGUSR1 没 有 机 会 被 递送 给 进程 。 

















上 面 的 代码 虽然 完成 了 等 待 某 特 定 信 号 的 任务 ， 但 是 它 也 有 副作用 ， 就 是 在 等 待 特定 信号 期 间 ， 
所 有 的 其 他 信和 号 都 不 能 递送 ， 原 因 是 sigsuspend 的 mask 阻 塞 了 SIGUSR1 以 外 的 所 有 信和 号， 导致 其 他 信和 号 
无 法 正常 递送 。 























下 面 的 代码 对 这 种 情况 做 了 改进 : 





static volatile sig atomic t sig received flag = 0; 
Sigset _ t mask blocked, mask ， old, mask unblocked; 
int signum = SIGUSR1; 

sigprocmask (SIGSETMASK, NULL, &mask blocked); 
sigprocmask (SIGSETMASK, NULL, gmask unblocked); 
sigaddset (&mask blocked,signum); 
sigdelset (gmask unblocked,signum); 

/* 将 





SIGUSR1 添 加 到 阻塞 掩 码 中 ， 确 保 下 面 判 断 


sig received flag 和 


Sigsuspend 之 间 不 会 收 到 


SIGUSR1 信 号 ， 从 而 导致 


SIGUSR1 错 失 


yA 
sigprocmask (SIG BLOCK, smask blocked, smask o1d); 
/*sigsuspend 返 回 ， 可 能 是 由 其 他 信号 引起 的 ， 


* 因 此 需要 再 次 判断 


Sig received flag 是 否 置 


1*/ 

while(sig received flag == 0) 
sigsuspend(&mask unblocked); 

/* 将 信号 恢复 成 默认 值 


人 
sigprocmask (SIG SETMASK, gmask old,NULL); 





上 面 的 例子 不 仅 做 到 了 等 待 特定 信号 SIGUSR1， 而 且 期 间 如 果 有 其 他 信号 ， 也 不 会 影响 其 他 信和 号 
的 递送 。 至 此 等 待 特定 信号 的 任务 算是 圆满 地 解决 了 。 








6.10.3 sigwait 函 数 和 Sigwaitinfo 函 数 























sigsuspend 函 数 可 以 实现 等 待 特定 信号 的 任务 ， 但 是 上 面 的 示例 过 于 繁复 ， 不 够 直接 。sigwait 系 列 函 数 就 可 以 比较 优雅 地 等 待 
某 个 特定 信号 的 到 来 。sigwait 系 列 函 数 提供 了 一 种 同步 接收 信号 的 机 制 ， 代 码 如 下 : 























#include <signal.h> 

int sigwait (const sigset t *set, int *sig); 

int sigwaitinfo (const sigset t *set, siginfo t *info); 

int sigtimedwait (const sigset t *set, siginfo - 七 *info, 
const struct timespec *timeout); 





















































ep 





三 个 函数 虽然 接口 上 有 差异 ， 但 是 总 体 来 说 做 的 事情 是 一 样 的 。 信 号 集 set 里 面 的 信号 是 进程 关心 的 信号 。 当 调用 sigwait 系 
列 函 数 中 的 任何 一 个 时 ， 内 核 会 查看 进程 的 信号 挂 起 队列 〈 包 括 私有 挂 起 队列 和 线程 组 共享 的 挂 起 队列 ) ， 检 查 set 中 是 否 有 信和 号 
处 于 挂 起 状态 。 如 果 有 ， 那 么 sigwait 相 关 的 函数 会 立刻 返回 ， 并 将 信号 从 相应 的 挂 起 队列 中 移 除 ， 如 果 没 有 ， 进 程 就 会 陷入 阻塞 ， 
进入 可 中 断 的 睡眠 状态 ， 直 到 进程 醒 来 ， 再 次 检查 挂 起 队列 。 












































































































































上 面 是 这 三 个 函数 的 共同 之 处 ， 不 过 它们 在 接口 设计 上 有 些许 差异 。 



































对 于 sigwait 函 数 ， 成 功 返 回 时 ， 返 回 值 是 0， 并 将 导致 函数 返回 的 信号 记录 在 sig 指 向 的 地 址 中 。 如 果 sigwait 调 用 失败 ， 则 返 
值 不 是 -1， 而 是 直接 将 errno 返 
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sigwaitinfo 函 数 是 升级 加 强 版 的 sigwait， 通 过 它 可 以 获取 到 信和 号 相关 的 更 多 信息 。 当 第 二 个 siginfo t 结 构 体 类 型 的 指针 info 不 是 
NULL 时 ， 内 核 会 将 信号 相关 的 信息 填 入 该 指针 指向 的 地 址 ， 从 而 获得 导致 函数 返回 的 信号 的 详细 信息 。 和 sigwait 函 数 不 同 ， 如 果 
sigwaitinfo 函 数 成 功 返 回 ， 那 么 返回 值 则 是 导致 函数 返回 的 信号 的 值 〈signo) ， 而 不 是 0; 如 果 sigwaitinfo 函 数 失败 ， 则 会 返回 -1， 
并 置 errno。 

































































sigtimedwait 函 数 和 sigwaitinfo 函 数 几乎 是 一 样 的 ， 除 了 前 者 约定 了 一 个 timeout 时 间 之 外 。 如 果 到 了 timeout 时 间 ， 还 未 等 到 set 中 
的 信号 ，sigtimedwait 就 不 再 继续 等 待 了 ， 而 是 返回 -1， 
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并 置 errno 为 EAGAIN。 









































sigwait 系 列 函 数 的 本 质 是 同步 等 待 信号 的 到 达 ， 所 以 不 需要 编写 信号 处 理 函 数 。 需 要 提示 的 是 ， 纵 然 某 信号 遭 到 了 阻 
塞 ，sigwaitinfo 依 然 可 以 获取 等 待 信号 。 



























































看 到 这 里 ， 不 知道 读者 有 没有 意识 到 ， 引 入 了 sigwait 系 列 函 数 之 后 ， 其 实 也 引入 了 竞争 。 正 常 的 信号 处 理 流程 ， 会 从 信号 挂 起 
队列 中 摘 取 信号 递送 给 进程 ， 而 sigwait 函 数 也 会 从 信号 挂 起 队列 中 摘 取 信号 ， 返 回 给 调用 进程 ， 两 者 成 了 抢 生意 的 关系 ， 如 图 6-5 
所 示 。 






























































get signal to deliver do sigtimedwait 

















dequeue signal 


6-5 sigwait 和 内 核 递送 信号 的 竞争 关系 
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所 以 在 调用 sigwait 系 列 函 数 之 前 ， 首 先 需要 将 se 





一 


中 的 信号 阻塞 ， 并 将 set 中 信号 的 独家 经 营 权 拿 到 手 ， 否 则 ， 如 果 调 用 





















































sigwaitinfo 之 前 或 两 次 sigwaitinfo 之 间 有 信和 号 到 达 ， 很 有 可 能 会 被 正常 地 递送 给 进程 ， 进 而 执行 注册 的 信号 处 理 函 数 〈 如 果 有 的 话 ) 
或 执行 默认 操作 SIG_DFL。 











sigwait 系 列 函数 的 典型 使 用 方式 如 下 : 


int Sigusr1l = 0; 
sigemptyset (&mask sigusr1) 
sigaddset (&mask sigusrl,SIGUSR1); 
sigprocmask (SIG SETMASK, &mask sigusr]l, NULL) ， 
while (1) 下 
{ 
sig = sigwaitinfo(&mask sigusrl,&si); 
if(sig != -1) 
{ 


sigusrl1 count++;} 


本 


本 这 个 例子 是 统计 收 到 SIGUSR1 的 次 数 。 在 调用 sigwaitinfo 之 前 ， 需 要 先 调用 sigprocmask 将 等 待 的 信号 屏蔽 。 






































上 上 






































] 超 时 却 没有 等 到 任何 信 
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sigtimedwait 函 数 的 用 法 和 sigwaitinfo 函 数 类 似 ， 只 不 过 timeout 参 数 指定 了 最 大 的 等 待 时 长 。 如 果 调 


号 ， 那 么 sigtimedwait 就 返回 -1， 并 且 设 errno 为 EAGAIN。 


























最 后 ，SIGKILL 和 SIGSTOP 不 能 等 待 ， 尝 试 等 待 IIGKILL 和 SIGSTOP 会 被 忽略 。 原 因 和 无 法 更 改 SIGKILL 和 SIGSTOP 信 号 的 信号 


处 理 函 数 一 样 。 











6.11 通过 文件 描述 符 来 获取 信和 号 


从 内 核 2.6.22 版 本 开始 ，Linux 提 供 了 另外 一 种 机 制 来 接收 信号 : 通过 文件 描述 符 来 获取 信和 号 即 
signal 亿 机 制 |。 


这 个 机 制 和 sigwaitinfo 非 常 地 类 似 ， 都 属于 同步 等 待 信号 的 范畴 ， 都 需要 首先 调用 sigprocmask 将 关 
注 的 信号 屏蔽 ， 以 防止 被 信号 处 理 函 数 动 走 。 不 同 之 处 在 于 ， 文 件 描述 符 方法 提供 了 文件 系统 的 接 
口 ， 可 以 通过 select、poll 和 epoll 来 监控 这 些 文件 描述 符 。 








signalfd 接 口 的 定义 如 下 : 





#include <sys/signalfd.h> 
int signalfd(int fd, const sigset 七 *mask, int flags); 











其 中 ，mask 参 数 是 信号 集 ， 表 示 关 注 信号 的 集合 。 这 些 信号 的 集合 应 该 在 调用 signalfa 函 数 之 前 ， 
先 调用 sigprocmask 函 数 阻塞 这 些 信 和 号， 以 防止 被 信号 处 理 函 数 动 走 。 





首次 创建 时 包 参 数 应 该 为 -1， 该 函数 会 创建 一 个 文件 描述 符 ， 用 于 读 取 mask 中 到 来 的 信号 。 如 有 果 亿 
不 是 -1， 则 表示 是 修改 操作 ， 一 般 是 修改 mask 的 值 ， 此 时 锯 是 之 前 调用 signalfa 时 返回 的 值 。 














第 三 个 参数 flags 用 来 控制 行为 ， 目 前 支持 的 标志 位 如 下 。 





:SFD CLOEXEC: 和 普通 文件 的 OCLOEXEC 一 样 ， 调 用 exec 函 数 时 ， 文 件 描述 符 会 被 关闭 。 





:SFD_NONBLOCK: 控制 将 来 的 读 取 操作 ， 如 果 执 行 read 操 作 时 ， 并 没有 信号 到 来 ， 则 立刻 返回 失 
败 ， 并 设置 errno 为 EAGAIN。 











创建 文件 描述 符 后 ， 可 以 使 用 read 函 数 来 读 取 到 来 的 信号 。 提 供 的 缓冲 区 大 小 一 般 要 足以 放下 一 个 
signalfa_ siginfo 结 构 体 ， 该 结构 体 一 般 包 括 如 下 成 员 变量 : 








struct signalfd siginfo { 
uint32 t ssi signo; 
int32 t ssi errno; 
int32 七 ssi code; 
Uint32. t SSi. Pid 
uint32 t ssi uid; 
int32 和 ssi fd; 
uint32 七 ssi tid; 
t ssi pand; 
uint32 t ssi overrun; 
七 ssi trapno; 
nt t.. Csi. Statwes; 
int32 七 ssi ints 
uint64 t ssi ptr; 
uint64 t ssi utime; 
七 ssi stime; 
tt ssi addr; 
uint8 t padlx]; 











这 个 结构 体 和 前 面 提 到 的 siginfo 结构 体 几乎 可 以 一 一 对 应 。 含 义 和 siginfo_t 中 的 成 员 也 一 样 ， 在 
此 就 不 再 次 述 了 。 





使 用 signal 季 来 接收 信号 的 方法 如 下 此 处 忽略 了 一 些 异 常 处 理 ) : 


sigprocmask (SIG BLOCK, gmask, NULL); 
sfd = signalfd(-1, &mask, NULL); 
for(;;) 
{ 
n = readl(sfd,&fd siginfo,sizeof (struct signalfd siginfo)); 
if(n != sizeof (struct signalfd siginfo)) 
{ 
/*error handle*/} 
elsel{ 
/*process the signal*/} 




















比较 推荐 的 做 法 是 用 文件 描述 符 signalfd 和 sigwaitinfe 两 种 方法 来 处 理 信 号 ， 使 用 传统 信号 处 理 函 数 
会 因为 异步 带 来 很 多 问题 ， 大 量 的 函数 因 不 是 异步 信号 安全 的 ， 而 无 法 用 于 信和 号 处 理 函 数 。 本 节 介 绍 


的 signalfd 方 法 更 加 值得 推荐 ， 因 为 方法 简单 ， 且 可 以 和 select、poll 和 epoll 函 数 配合 使 用 ， 非 常 灵 活 。 























6.12 ”信和 号 递送 的 顺序 


有 一 个 非常 有 意思 的 话题 ， 当 有 多 个 处 于 挂 起 状态 的 信号 时 ， 信 和 号 递送 的 顺序 又 是 如 何 的 呢 ? 








信号 实质 上 是 一 种 软 中 断 ， 中 断 有 优先 级 ， 信 号 也 有 优先 级 。 如 果 一 个 进程 有 多 个 未 决 信号 ， 那 么 对 于 同一 个 未 决 的 实时 信号 ， 内 核 将 按 
来 递送 信号 。 如 果 存 在 多 个 未 决 的 实时 信号 ， 那 么 值 〈 或 者 说 编号 ) 越 小 的 越 优先 被 递送 。 如 果 既 存在 不 可 靠 信号 ， 又 存在 可 靠 
信号 《实时 信号 ) ， 虽 然 POSIX 对 这 一 情况 没有 明确 规定 ， 但 Linux 系 统 和 大 多 数 遵循 POSIX 标 准 的 操作 系统 一 样 ， 即 将 优先 递送 不 可 靠 信 号 。 
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虽然 是 优先 递送 不 可 靠 信号 ， 但 在 不 可 靠 信 号 中 ， 不 同 信号 的 优先 级 又 是 如 何 的 呢 ? 内 核 如 何 实现 这 些 这 些 优先 级 的 顺序 呢 ? 











内 核 选择 信号 递送 给 进程 的 流程 如 图 6-6 所 示 。 


get signal to deliver dequeue signal __dequeue signal 


图 6-6 内核 选择 信号 的 流程 


下 面 来 分 析 相 关 的 代码 : 





int dequeue signal (struct task struct *tsk, 
sigset 七 *mask, siginfo t *info) 
{ 
int signrs 
/* We only dequeue private signals from ourselves, we don't let 
* signalfd steal them 
人 


/* 线 程 私有 的 挂 起 信号 队列 优先 


大 
/ 
signr = dequeue signal(&tsk->pending, mask, info); 
if (!signr) { 和 
signr = dequeue signal (&tsk->signal->shared pending, 
~ mask, info); 和 


















































前 文 讲 过 ， 线 程 的 挂 起 信号 队列 有 两 个 : 线程 私有 的 挂 起 队列 (pending) 和 整个 线程 组 共享 的 挂 起 队列 〈signal->shared pending) 。 如 上 面 
的 代码 所 示 ， 选 择 信 号 的 顺序 是 优先 从 私有 的 挂 起 队列 中 选择 ， 如 果 没 有 找到 ， 则 从 线程 组 共享 的 挂 起 队列 中 选择 信号 递送 给 线程 。 当 然 选择 
的 时 候 需 要 考虑 线程 的 阻塞 掩 码 ， 属 于 阻塞 掩 码 集中 的 信号 不 会 被 选 出 。 
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在 挂 起 信号 队列 (无 论 是 共享 挂 起 队列 还 是 私有 挂 起 队列 ) 中， 选择 信号 的 工作 交 给 了 next_signal 函 数 ， 其 逻辑 如 下 : 




















int next signall(struct sigpending *pending, sigset t *mask) 
{ 
Unsigned Jong i *Sr WwW x 
int sig = 0; 
s = pending->signal.sig; 
m= mask->sig; 
/* 
* Handle the first word specially: it contains the 
* synchronous signals that need to be dequeued first. 
A 


x 
if (x) { 
/* 优 先 选择 同步 信号 ， 所 谓 同步 信号 集合 就 是 


SIGSEGV、 


SIGBUS 等 六 种 信号 


if (x & SYNCHRONOUS_ MASK) 
x &= SYNCHRONOUS MASK; 
/* 小 信号 值 优先 递送 的 算法 
FE 
sig = ffz (~x) 
+ 并 区 


return sig; 


SWjt 
defa 


Case 


Case 


} 

retu 
} 
#define 


ch (_NSIG WORDS) { 

kn 

for (i = 1 i < NSIG WORDS; ++i) { 
X= *++S &~ +tm; 


if (!x) 
continue; 
Sig = ffz(~x) + i* NSIG BPW + 1; 
break; 
} 
break; 
x= s[1] &~ m[1]; 
Ey 
break; 
sig = ffz(~x) + NSIG BPW + 1; 
break; 和 加 
/* Nothing to do */ 
break; 
rh i 


SYNCHRONOUS MASK \ 


(sigmask (SIGSEGV) | sigmask(SIGBUS) | sigmask(SIGILL) | \ 
Sigmask (SIGTRAP) | sigmask (SIGFPE) | sigmask (SIGSYS)) 


























1) 出 


2) 优 








1 于 不 同 平台 long 的 长 度 不 同 ， 所 以 算法 略 有 不 同 ， 但 是 思想 是 一 样 的 ， 如 下 。 




















现在 阻塞 掩 码 集中 的 信号 不 能 被 选 出 。 





TI 








先 选择 同步 信号 ， 所 谓 同步 信号 指 的 是 以 下 6 种 信号 : 








{SIGSEGV, SIGBUS, SIGILL, SIGTRAP, SIGFPE, SIGSYS} 





这 6 种 


3) 如 


4) 如 





























言 号 都 是 与 硬 


F 相 关 的 信号 。 




















果 没 有 上 面 6 种 信号 ， 非 实时 信号 优先 ; 如 果 存 在 多 种 非 实 时 信号 ， 小 信号 值 的 信号 优先 。 


























果 没 有 非 实 时 信号 ， 那 么 实时 信号 按照 信号 值 递送 ， 小 信号 值 的 信号 优先 递送 。 





通过 下 面 的 测试 程序 来 验证 是 否 如 此 : 

















#include 
#include 
#include 
#include 
#include 
#include 
static 1 
static n 
int sigo 
#define 

void han 


{ 


<stdio.h> 
<atdlib,h> 
<unistd.h> 
<signal.h> 
<string.h> 
<errno.h> 
nt sig cnt[NSIG]; 
umber= 0 ; 
rder[128]= {0}; 
MSG "#%d:receiver signal %d\n" 
dler (int signo) 


/* 此 处 最 好 判断 一 下 


number 的 值 ， 不 要 超出 数组 的 长 度 


$¥ 
sigo. 

} 

int main 

{ 
int 
int 
sigs 
sigs 
sigs 
stru 
sigf 

#ifdef U 
sa.s 
Sa.s 
sa.s 

#endif 
ri 
forl( 


上 
#ifdef U 


#else 


#endif 


水 
nt 
ifl(s 
. 


} 
prin 
sleel 


rder [numbert++] = signo; 
(int argc,char* argv[]) 


冰 Qs 

k La 

et t blockall mask ; 
et t pending mask ; 
et 七 empty mask ; 

ct sigaction sa; 
illset (&blockall mask); 
SE_SIGACTION 加 
a_handler = handler; 

a mask = blockall mask :， 
a flags = SA RESTRRT ; 


tf("%s:PID is %d\n",argv[0],getpid()); 
1 二 1 1 < NSIG; i++) 


if(i == SIGKILL || i == SIGSTOP) 
continue; 

SE_SIGACTION 

if(sigaction(i,é&sa, NULL) !=0) 


if(signal (i,handler)== SIG ERR) 


{ 
fprintf (stderr, "sigaction for signo(%d) failed (%s)\n",i, strerror (errno)); 
ea return -1; 
} 


sleep time = atoi (argv[1]); 
igprocmask (SIG SETMASK, &gblockall mask,NULL) == -1) 


fprintf (stderr,"setprocmask to block all signal failed(%s)\n",strerror(errno)); 
return -2} 


tf("I will sleep %d second\n", sleep time); 
p(sleep time); 


sigemptyset (&empty mask); 
if(sigprocmask (SIG SETMASK, gempty mask,NULL) == 
‘ 


fprintf (stderr,"setprocmask to release all signal failed(%s)\n",strerror (errno)); 


return -3; 


} 

sleep (3) 
for(li=0. 
{ 


i< number ; i++) 
if(sigorder[i] != 0) 
{ 


printf ("#%d: signo=%d\n",i,sigorder[i]); 
} 
} 


return 0; 














注意 上 面 的 代码 必须 要 定义 USE_SIGACTION 宏 ， 
断 ， 会 导致 无 法 得 到 信号 的 真实 递送 顺序 。 










































































上 述 程序 首先 会 安装 所 


命令 向 进程 发 送 各 种 信号 ， 















































函数 期 间 ， 需 要 屏蔽 掉 其 





有 信和 号 的 信号 处 理 函 数 〈SIGKILL 和 SIGSTOP 除 外 ) ， 然 后 阻塞 所 有 























他 信号 ， 和 否则 信号 处 理 函 数 被 其 他 信号 打 








= 











之 后 睡眠 一 段 时 间 ， 在 这 段 时 间 内 ， 通 过 


























BY 











旦 睡眠 结束 ， 解 除 阻塞 ， 信 号 就 会 被 递送 给 进程 ， 进 程 就 会 执行 信号 处 理 函 数 。 


























照 递送 的 顺序 ， 被 记录 在 静态 数组 中 。 只 














言 号 处 理 函数 是 精心 定制 的 ， 按 


按 顺 序 打印 出 信号 的 值 ， 就 可 获得 信号 的 递送 顺序 : 





gcc -Oo sigaction delivery order -DUSE SIGACTION signal delivery order.c 

















向 进程 发 送信 号 的 脚本 如 下 : 








#!/bin/bash 


./sigaction delivery order 30 & 
signal pid=5! 站 

Sleep 2 

kill -10 S$signal pid 

kill -3 S$signal pid 

kill -12 S$signal pid 

kill -11 S$signal pid 

kill -39 S$signal pid 

kill -2 S$signal pid 

kill -5 $signal pid 

kill -4 S$signal pid 

kill -36 S$signal pid 

kill -24 S$signal pid 

kill -38 S$signal pid 

kill -37 S$signal pid 

kill -31 S$signal pid 

kill -8 S$signal pid 

kill -7 S$signal pid 

./tkill -p $signal pid -s 44 














tkill 是 发 给 具体 线程 的 ， 信 号 会 挂 在 线程 私有 
4=SIGILL、5=SIGTRAP、7=SIGBUS、8=SIGFPE、 














的 挂 起 信号 队列 上 ， 所 以 会 优 # 
11=SIGSEGV、31=SIGSYS， 这 些 都 





Et 递送 ， 因 此 44 号 信号 应 该 第 一 个 被 递送 ， 则 











他 的 信号 中 











yy 





br 











于 同步 信号 集合 ， 紧 随 44 号 信号 之 后 ， 按 照 从 小 到 大 的 





















































顺序 递送 ; 2、3、10、12、24 作 为 非 实 时 信和 号， 再 随 划 
进程 。 
测试 的 输出 结果 如 下 所 示 : 








后 被 递送 ， 最 后 是 实时 信和 号， 按照 从 小 到 大 的 顺序 〈 即 36、37、38、39) ， 依 次 递送 给 





root@manu-hacks:~/code/c/self/signal# ./test order.sh 
./sigaction delivery order:PID is 21897 网 
sigaction for signo(32) failed (Invalid argument) 
sigaction for signo(33) failed (Invalid argument) 

I will sleep 30 second 
root@manu-hacks:~/code/c/self/signal# #0: signo=44 


#1: signo=4 
#2: signo=5 
#3: signo=7 
#4: signo=8 
#5: signo=11 
#6: signo=31 
#7: signo=2 
#8: signo=3 
#9: signo=10 
#10: signo=12 
#11: signo=24 
#12: signo=36 
#13: signo=37 
#14: signo=38 
#15: signo=39 














和 预想 的 一 样 ， 信 号 就 是 按照 这 四 个 优先 级 递送 给 进程 的 。 








6.13 异步 信号 安全 


设计 信号 处 理 函 数 是 一 件 很 头疼 的 事 











坟 
河 
el 




















就 藏 在 图 6-7 中 。 当 内 核 递送 信号 给 进程 时 ， 进 程 正在 执行 的 指令 序列 就 会 被 中 断 ， 转 而 执行 
信号 处 理 函数 。 待 信号 处 理 函 数 执行 完毕 返回 (如 果 可 以 返回 的 话 ) ， 则 继续 执行 被 中 断 的 正常 指令 序列 。 此 时 ， 问 题 就 来 了 ， 同 一 个 进程 中 
出 现 了 两 条 执行 流 ， 而 两 条 执行 流 正 是 信号 机 制 众多 问题 的 根源 。 
























































主 程序 


信号 处 理 函 数 


S| 


执行 信号 
处 理 函 数 
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图 6-7 进程 收 到 信号 的 处 理 流程 











在 信号 处 理 函 数 中 有 很 多 函数 都 不 可 以 使 用 ， 
诡异 的 bug。 


























Ss 




















有 因 就 是 它们 并 不 是 异步 信号 安全 的 ， 强 行使 用 这 些 不 安全 的 函数 隐患 





Tum 
jmh 
um 














， 还 可 能 带 来 很 

















引入 多 线程 后 ， 很 多 库 函 数 为 了 保证 线程 安全 ， 不 得 不 使 用 锁 来 保护 临界 区 《〈 见 表 6-17) 。 比 如 malloc 就 是 一 种 典型 的 场景 。 



































表 6-17 锁 来 保证 线程 安全 









































时 间 线程 1 执行 流 线程 2 执行 流 
加 锁 保 护 临 界 区 的 方法 ， 虽 然 不 可 重 入 ， 却 是 实现 线程 安全 的 一 种 选择 。 但 是 这 种 方法 无 法 保证 异步 信号 安全 见 表 6-18。 
表 6-18 锁 无 法 保证 异步 信号 安全 
时 间 主 程序 执行 流 信号 处 理 函 数 执行 流 






































还 是 以 malloc 为 例 ， 如 果 主 程序 执行 流 调用 malloc 已 经 持 有 了 锁 ， 但 是 尚未 完成 临界 区 的 操作 ， 这 时 候 被 信号 中 断 ， 转 而 执行 信号 处 理 函 
数 ， 如 果 信和 号 处 理 函 数 中 再 次 调用 malloc 加 锁 ， 就 会 发 生死 锁 。 













































































由 





从 上 面 的 讨论 可 以 看 出 ， 异 步 信号 安全 是 一 个 很 苛刻 的 条 件 。 事 实 上 只 有 非常 有 限 的 函数 才能 保证 异步 信号 安全 。 


等 不 可 控制 的 时 序 条 件 ， 


1. 轻 


一 般 说 来 ， 不 安全 的 








函数 大 抵 上 可 以 分 为 以 下 几 种 情况 : 



































-使 用 了 静态 变量 ， 典 型 的 是 strtok、localtime 等 函数 。 
-使 用 了 malloc 或 free 函 数 。 





-标准 W/O 函数 ， 如 printf。 














读者 可 以 通过 man 7 signal 的 Async-signal-safe functions 小 节 查 看 异 
































所 电 

















Na 


全 的 函数 列表 ， 在 此 就 不 罗列 了 。 本 和 
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中 j 


站 








用 了 printf 函 


数 ， 








在 正 











且 面 工作 得 很 











正 的 工程 代码 中 ， 


J 





函数 中 的 。 





其 实 这 是 不 对 的 ， 在 是 不 允许 非 异步 信号 安全 的 函数 出 现在 信号 处 理 






































的 函数 ， 在 异步 信号 的 条 件 下 ， 会 日 








常 程序 流量 





既然 


三 
日 





这 是 一 种 比较 常见 的 做 法 ， 就 是 信号 处 到 


这 种 








Tm 
lill 
Hn 





村 





陷 B 








， 蛋 




















做 法 可 








伪 代 码 的 




















很 难 重 现 。 因 此 编写 信号 处 理 函数 就 像 将 船 驶 入 暗礁 从 生 的 海域 ， 不 可 不 小 心 。 














该 如 何 使 用 信号 机 制 呢 ? 


级 信号 处 理 函 数 





怀 大 


函数 非常 短 ， 基 本 就 是 设置 标志 位 ， 然 后 由 了 




















如 下 : 


乡 式 表示 ， 





FP 有 很 多 地 方 在 信号 


H 现 很 诡异 的 bug。 这 种 bug 的 触发 ， 经 常 依赖 信号 到 达 的 时 间 、 进 
































en 


程 





程序 执行 流 根据 标志 位 来 获知 信号 已 经 到 达 。 





volatile sig atomic 七 get SIGINT = 0; 
/* 信 号 处 理 函 数 


void sigint handler (int sig) 


switch (sig){ 


/* 主 程序 流 是 一 个 循环 


while (true) 


if(get SIGINT==1) 


/* 在 主 程序 流 中 处 理 


SIGINT*/ 
} 


1 


case SIGINT: 


get _ SIGINT = 1 break; 


job = get next job(); 


do : 





否 收 到 某 信 号 。 


这 是 一 种 常见 的 设计 ， 信 号 处 理 函数 非 
若 收 到 信号 ， 则 执行 相应 的 操作 ， 通 常 


single job (job); 





As 


吊 间 里， 





， 仪 仅 是 设置 了 一 个 标志 位 。 程 序 的 3 


志 重新 清 零 。 



































一 般 来 讲 定义 标志 的 时 候 ， 会 将 标志 的 类 型 定义 成 : 


FE 流 程 会 周期 性 地 检查 标志 ， 以 此 来 





间断 是 





volatile sig atomic t flag; 

























































































































































































sig atomic_t 是 C 语 言 标 志 定 义 的 一 种 数据 类 型 ， 该 数据 类 型 可 以 保证 读 写 操作 的 原子 性 。 而 volatile 关 键 字 则 是 告诉 编译 器 ，flag 的 值 是 易 变 
的 ， 每 次 使 用 它 的 时 候 ， 都 要 到 flag 的 内 存 地 址 去 取 。 之 所 以 这 么 做 ， 是 因为 编译 器 会 做 优化 ， 编 译 器 如 果 发 现 两 次 取 flag 值 之 间 ， 并 没有 代码 
修改 过 flag， 就 有 可 能 将 上 一 次 的 flag 值 拿 来 用 。 而 由 于 主 程序 和 信和 号 处 理 不 在 一 个 控制 流 之 中 ， 因 此 编译 器 几乎 总 是 会 做 这 种 优化 ， 这 就 违背 
了 设计 的 本 意 。 因 此 使 用 volatile 来 保证 主 程序 流 能 够 看 到 信号 处 理 函 数 对 flag 的 修改 。 
2. 化 异步 为 同步 

由 于 信和 号 处 理 函 数 的 存在 ， 进 程 会 同时 存在 两 条 执行 流 ， 这 带 来 了 很 多 问题 ， 因 此 操作 系统 也 想 了 一 些 办 法 ， 就 是 前 面 提 到 的 sigwait 和 
signalfd 机 . 制 |。 





sigwait 的 设计 本 意 是 同步 地 
FP， 而 等 待 信号 降临 的 使 命 ， 一 般 落 在 3 


包 计 人 








在 多 线程 的 程 








号 。 在 执行 流 中 ， 执 行 sigwait 函 数 会 陷入 阻塞 ， 直 到 等 待 的 信号 降临 。 一 般 来 讲 ，sigwait 朋 
线程 身上 。 有 具体 做 法 如 下 : 





款 件 售 

















sigfillset (&set al1) 
sigprocmask (SIG SETMASK, &set all,NULL); 
for(;;) 
{ 

ret = sigwait (&set all,&signo): 


/* 处 理 收 到 的 


signo*/ 
} 

















sigwait 昌 然 化 异步 为 同步 ， 但 是 也 废 掉 了 一 条 执行 流 。signal 和 包机 制 则 提供 了 另外 一 种 思路 : 











#include <sys/signalfd.h> 
int signalfd(int fd, const sigset t *mask, int flags); 





有 具体 步 又 如 下 : 





tr 


1) 将 关心 的 信号 放 入 集合 。 





2) 调用 sigprocmask 函 数 ， 阻 塞 关心 的 信和 号 。 





I 


一 个 文件 描述 符 。 





3) 调用 signal 人 函数 ， 返 





















































有 了 文件 描述 符 ， 就 可 以 使 用 select/poll/epoll 等 WO 多 路 复 用 函数 来 监控 它 。 这 样 ， 当 信号 来 临时 ， 就 可 以 通过 read 接 口 来 获取 到 信号 的 相关 








二 轴 
Bi: 























struct signalfd info signalfd info; 
read (signal fqd,&signalfd info,sizeof(struct signalfd info)); 
























































在 引入 signalfda 机 制 以 前 ， 有 一 种 很 有 意思 的 化 异步 为 同步 的 方式 被 广泛 使 用 。 这 种 技术 被 称 为 “selfpipe trick”。 简 单 地 讲 ， 就 是 打开 一 个 无 














管道 ， 在 信号 处 理 函 数 中 向 管道 写 入 一 个 字 节 (write 函 数 是 异步 信号 安全 的 ) ， 而 主 程序 从 无 名 管道 中 读 取 一 个 字 节 。 通 过 这 种 方式 也 做 到 








了 在 主 程序 流 中 人 处理 信号 的 目的 。 























《Linux 高 性 能 服务 器 编程 》 一 书 中 ， 在 “统一 事件 源 ” 一 节 中 详细 介绍 了 这 个 技术 。 不 过 使 用 的 不 是 无 名 管道 ， 而 是 socketpair 函 数 。 











static int pipefd[2] 
/* 信 号 处 理 函 数 中 ， 向 


socketpair 中 写 入 


1 个 字 节 ， 即 信号 值 


wy 
void sig handler (int sig) 


int save errno = errno; 

int msg = sig; 

send (pipefd[1], (char*) gmsg,1,0); 

errno = save errno }; 
} 
ret = socketpair (PF UNIX,SOCK STREAM,0,pipefd); 
/* 当 


工 /O 多 路 复 用 函数 ， 侦 测 到 


Pipefd [0] ， 有 内 容 到 来 时 ， 则 使 用 


ecV 读 取 


i# 
char signals[1024]; 
ret = recv(pipefd[0],signals,sizeof (signals),0); 





将 socketpair 的 一 端 置 于 selectpollyepoll 等 函数 的 监控 下 ， 当 信和 号 到 达 的 时 候 ， 信 和 号 处 到 





























函数 会 


往 socketpair 的 另 





端 写 入 1 个 字 节 ， 即 信号 的 





值 。 此 时 ， 了 


所 








E 程 序 的 select/poll/epoll 函 数 就 能 侦 测 到 此 事 ， 


= 

















对 socketpair 执 行 recv 操 作 ， 获 取 到 信和 号 处 理 函 数 写 入 的 信号 值 ， 进 


行 相应 的 处 理 。 


6.14 总结 











Linux 的 signal 机 制 是 一 种 原始 的 进程 间 通 信 机 制 ， 传 递 的 信息 有 限 ， 很 难 传递 复杂 的 消息 ， 加 上 信 
号 处 理 函 数 和 进程 处 于 两 条 执行 逻辑 流 ， 会 带 来 函数 的 重 入 问题 ， 因 此 signal 机 制 不 适合 作为 进程 间 通 
信 的 主要 手段 。 但 是 信号 义 不 是 完全 无 用 的 ， 对 于 某 些 不 频 莹 发 生 的 异步 事件 ， 还 是 可 以 使 用 signal 来 
通知 进程 。 























第 7 章 ”理解 Linux 线 程 (1) 





相对 于 Unix 操 作 系 统 40 多 年 的 光辉 历史 ， 线 程 算是 出 现 得 比较 晚 的 。 在 20 世 纪 90 年 代 线 程 才 慢 慢 
流行 起 来 ， 而 POSIX threads 标 准 的 确立 已 经 是 1995 年 的 事情 了 。 














Unix 原 本 是 不 支持 线程 的 ， 线 程 概念 的 引入 给 Unix 家 族 带 来 了 一 些 贱 烦 ， 很 多 函数 都 不 是 线程 安 
(thread-safe〉 的， 需要 重新 定义 ， 信 号 机 制 在 线程 加 入 以 后 也 变 得 更 加 复杂 了 。 














在 单 核 CPU 时 代 ， 多 线程 的 需求 并 没有 那么 强烈 ， 但 是 随 着 时 间 的 流逝 ， 事 情 发 生 了 变化 。2005 
年 3 月 ，Herb Sutter 在 Dobb's Journal 上 发 表 了 《The Free Lunch is over: A Fundamental Turn Toward 
Concurrency in Software》 一 文 ， 文 章 分 析 处 理 器 厂商 改善 CPU 性 能 的 传统 方法 ， 如 提升 时 钟 速度 和 指令 
吞吐 量 ， 基 本 已 经 走 到 了 尽头 ， 处 理 器 开始 向 超 线程 和 多 核 架 构 靠 拢 ， 多 核 的 时 代 已 然 来 临 。 为 了 让 
代码 运行 得 更 快 ， 单 纯 地 依赖 更 快 的 硬件 已 经 无 法 满足 要 求 。 程 序 员 需 要 编写 并 发 代码 ， 以 便 充分 发 
挥 多 核 处 理 器 的 强大 功能 ， 并 且 使 程序 的 性 能 得 到 提升 。 


























7.1 线程 与 进程 


























期 。 线 程 是 操作 系统 进程 调度 器 可 以 调度 的 最 小 执行 单元 。 进 程 和 线程 的 关系 如 图 7-1 所 示 。 
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单线 程 进程 多 线程 进程 
多 个 单线 程 进程 多 个 多 线程 进程 


图 7-1 ”线程 和 进程 的 关系 





























一 个 进程 可 能 包含 多 个 线程 ， 传 统 意义 上 的 进程 ， 不 过 是 多 线程 的 一 种 特例 ， 即 该 进程 只 包含 一 个 线程 。 


为 什么 要 有 多 线程 ? 











举 个 生活 中 的 例子 ， 这 就 好 比 去 银行 办 理 业务 。 到 达 银 行 后 ， 首 先 找到 领导 的 机 器 领取 一 个 号 码 ， 然 后 多 
望 ， 办 理 业 务 的 窗口 越 多 越 好 。 如 果 把 整个 营业 大 厅 当 成 一 个 进程 的 话 ， 那 么 每 一 个 窗口 就 是 一 个 工作 线程 。 








这 种 场景 在 Linux 中 





屡 见 不 旬 


MASTER THREAD 



































fF。 编 程 的 思想 (如 图 7-2 所 示 )〉 和 生活 中 解决 问题 的 想法 总 是 类 似 的 。 











在 Linux 下 ， 程 序 或 可 执行 文件 是 一 个 静态 的 实体 ， 它 只 是 一 组 指令 的 集合 ， 没 有 执行 的 含义 。 进 程 是 一 个 动态 的 实体 ， 有 自己 的 生命 周 








下 来 安心 等 待 。 这 时 候 你 一 定 希 


排队 等 待 区 





WORKERTHREAD 国 国 





WoRKER THREAD 大 国 
WORKERTHREAD 大国 


图 7-2 ”Master-Worker 并 发 模型 





有 人 说 不 必 非 要 使 用 线程 ， 多 个 进程 也 能 做 到 这 点 。 的 确 如 此 。UnixwLinux 原 本 的 设计 是 没有 线程 的 ， 类 Unix 系 统 包括 Linux 从 设计 上 更 倾向 














于 使 用 进程 ， 反 倒是 Windows 医 








进程 之 间 ， 彼 此 的 地 址 空间 是 独立 的 ， 但 线程 会 共享 内 存 地 址 空间 《〈 如 图 7-3 所 示 ) 。 同 一 个 进程 的 多 个 线程 共 寻 

















为 创建 进程 的 开销 巨大 ， 而 更 加 钟爱 线程 。 





那么 线程 是 不 是 一 种 设计 上 的 元 余 呢 ? 其 实 不 是 这 样 的 。 


初始 化 数据 段 、 未 初始 化 数据 段 和 动态 分 配 的 堆 内 存 段 。 

















EE 


局 内 存 区 域 ， 包 括 





Process 


share share 


线程 创建 














copy 


进程 创建 





图 7-3 ”线程 之 间 共 享 资源 








这 种 共享 给 线程 带 来 了 很 多 的 优势 : 














创建 线程 花费 的 时 间 要 少 于 创建 进程 花费 的 时 间 。 
































:终止 线程 花费 的 时 间 要 少 于 终止 进程 花费 的 时 间 。 








“线程 之 间 上 下 文 切换 的 开销 ， 要 小 于 进程 之 间 的 上 下 文 切 换 。 



































线程 之 间 数 据 的 共享 比 进程 之 间 的 共享 要 简单 。 






































下 面 用 一 个 简单 的 实验 ， 来 比较 下 创建 10 万 个 进程 和 10 万 个 线程 各 自 的 开销 。 
































创建 进程 的 测试 程序 将 会 执行 如 下 操作 : 

































































1) 调用 fork 函 数 创 建 子 进程 ， 子 进程 无 实际 操作 ， 调 用 exit 函 数 立刻 退出 ， 父 进程 等 待 子 进程 退出 。 























2) 重复 执行 步 又 1， 共 执行 10 万 次 。 





创建 线程 的 测试 程序 则 执行 如 下 操作 : 




















1) 调用 pthread_create 创 建 线 程 ， 线 程 无 实际 操作 :调用 pthread_exit 函 数 ， 立 刻 退 出 ， 主 线程 调用 pthread join 函数 等 待 线程 退出 。 





























2) 重复 执行 步骤 1， 共 执行 10 万 次 。 





























服务 器 CPU 的 情况 为 : Intel 2.1GHz Xeon E5-2620 (24 核 ) ， 下 而 














小 








进程 测试 


看 下 测试 结果 ， 见 表 7-1。 


长 7-1 ”创建 线程 或 子 进程 之 前 无 内 存 分 配 ， 程 序 耗 时 比较 


线程 测试 








从 测试 结果 上 看 ， 创 建 线程 花费 的 时 间 约 是 创建 进程 花费 时 间 的 五 分 之 一 。 






































ds 


在 上 述 测试 中 ， 
线程 不 需要 ， 则 两 者 之 间 效 率 上 的 差距 会 进一步 拉 大 ， 见 表 7-2。 














前 用 fork 函 数 和 pthread_create 函 数 之 前 ， 并 没有 分 配 大 块 内 存 。 一 旦 分 配 大 块 内 存 ， 考 虑 到 创建 进程 需要 拷贝 页 表 ， 而 创建 















































表 7-2 ”创建 线程 或 子 进程 之 前 ， 堆 上 分 配 了 40MB 空 间 















进程 测试 


100.631s 







线程 测试 















































线程 间 的 上 下 文 切换 ， 指 的 是 同一 个 进程 里 不 同 线程 之 间 发 生 的 上 下 文 切换 。 由 于 线程 原本 属于 同一 个 进程 ， 它 们 会 共享 地 址 空间 ， 大 量 资 
源 共 享 ， 切 换 的 代价 小 于 进程 之 间 的 切换 是 自然 而 然 的 事情 。 



































线程 之 间 通 信 的 代价 低 于 进程 之 间 通 信 的 代价 。 从 生活 的 角度 来 类 比 ， 部 门 内 的 协作 总 是 要 比 跨 部 门 的 协作 来 得 顺 溜 。 线 程 共享 地 址 空间 的 
设计 ， 让 多 个 线程 之 间 的 通信 变 得 非常 简单 。 一 个 进程 内 的 多 个 线程 ， 就 像 一 个 软件 研发 小 组 内 部 的 不 同 员工 ， 共 享 代码 、 服 务 器 、 打 印 机 、 资 
料 ， 彼 此 之 间 有 分 工 协作 ， 沟 通 协作 成 本 比较 低 。 进 程 之 间 的 通信 代价 则 要 高 很 多 。 进 程 之 间 不 得 不 采用 一 些 进 程 间 通信 的 手段 〈 如 管道 、 共 享 
内 存 及 信号 量 等 ) 来 协作 。 

































































































































































前 面 是 从 操作 系统 的 角度 来 分 析 线 程 优势 的 ， 从 用 户 或 应 用 的 视角 来 分 析 ， 多 线程 的 程序 也 有 很 多 的 优势 。 





























1. 发 挥 多 核 优势 ， 充 分 利用 CPU 资源 











CPU 是 一 种 资源 ， 如 果 一 方面 CPU 资源 大 量 闲 置 ， 处 于 IDLE 的 状态 ， 另 一 方面 很 多 任务 得 不 到 及 时 的 处 理 ， 处 于 排队 等 待 的 状态 ， 这 就 表明 
资源 没有 得 到 有 效 的 利用 ， 本 质 上 是 一 种 浪费 。 






























































可 以 想象 如 下 场景 :你 在 火车 站 买 票 ，10 个 售票 窗口 ， 有 9 个 窗口 的 售票 员 暂 停 服 务 ， 但 是 这 9 个 售票 员 却 在 嗜 瓜 子 ， 玩 手机 ， 大 厅 里 排队 者 
有 几 百 人 。 












































你 排 在 最 后 ! ! ! 








你 是 不 是 很 慎 候 。 是 的 ， 编 程 领域 也 一 样 ， 如 果 存 在 多 个 相同 的 任务 ， 彼 此 之 间 并 行 不 悖 ， 互 不 依赖 《〈 或 者 依赖 性 很 小 ) ， 那 么 启动 多 个 线 
程 并 发 处 理 ， 是 一 个 不 错 的 选择 《如 图 7-4 所 示 ) 。 虽 然 对 每 个 任务 而 言 ， 处 理 的 时 间 并 没有 缩短 ， 但 是 在 相同 时 间 内 ， 处 理 了 更 多 的 任务 。 
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图 7-4 并 发 执行 ， 充 分 利用 CPU 资源 














2. 更 自然 的 编程 模型 








有 很 多 程序 ， 天 生 就 适合 用 多 线程 。 将 工作 切 分 成 多 个 模块 ， 并 为 每 个 模块 分 配 一 个 或 多 个 执行 单元 ， 更 符合 人 类 解决 问题 的 思路 。 















































以 文本 编辑 程序 为 例 ， 用 户 的 输入 需要 及 时 响应 ， 必 须要 有 线程 来 监控 鼠标 和 键盘 ;如 果 用 户 删除 了 第 一 页 的 某 一 行 ， 后 面 很 多 页 的 格式 都 
会 受到 影响 ， 这 时 就 需要 有 文本 格式 化 线程 在 后 台 执行 格式 处 理 ; 很 多 文本 编辑 软件 都 有 自动 保存 的 功能 ， 第 三 个 线程 会 周期 性 地 将 文件 内 容 写 
入 磁盘 ;很 多 文本 编辑 软件 都 有 检测 拼写 错误 的 功能 ， 或 许 我 们 需要 第 四 个 线程 .……. 




































































[也 





上 述 的 分 工 是 很 自然 的 事情 ， 想 象 一 下 如 果 将 所 有 工作 都 放 在 一 个 单线 程 的 进程 


情 ? 程序 结构 也 就 会 变 得 异常 复杂 。 

















硬 ， 那 么 该 进程 是 不 是 就 不 得 不 处 理 庞杂 而 又 繁 芜 的 事 



































没有 银 弹 。 多 线程 带 来 优势 的 同时 ， 也 存在 一 些 浆 端 。 

















1) 多 线程 的 进程 ， 因 地 址 空间 的 共享 让 该 进程 变 得 更 加 脆弱 











多 个 线程 之 中 ， 只 要 有 一 个 线程 不 够 健壮 存在 bug〈 如 访问 了 非法 地 址 引发 的 段 错误 ) ， 就 会 导致 进程 内 的 所 有 线程 一 起 完蛋 。 正 所 谓 : 



































城 门 失火 ， 歼 及 池 鱼 
































相 比 之 下 ， 进 程 的 地 址 空间 互相 独立 ， 彼 此 隔离 得 更 加 彻底 。 多 个 进程 之 间 互 相 协同 ， 一 个 进程 存在 bug 导 致 异常 退出 ， 不 会 影响 到 其 他 进 














2) 线程 模型 作为 一 种 并 发 的 编程 模型 ， 效 率 并 没有 想象 的 那么 高 ， 会 出 现 复杂 度 高 、 易 出 错 、 难 以 测试 和 定位 的 问题 















































目前 存在 的 并 发 编程 ， 基 本 可 以 分 成 两 类 : 























共享 状态 式 


消息 传递 式 




















线程 模型 采用 的 是 





种 。 从 现在 开始 ， 停 止 幻想 ， 欢 迎 来 到 真实 的 世界 。 
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一 个 程序 员 碰 到 了 一 个 问题 ， 他 决定 用 多 线程 来 解决 。 现 在 两 个 他 问题 了 有 [1 。 











一 一 关于 线程 的 冷笑 话 












































在 真实 的 场景 中 ， 多 线程 编程 是 很 复杂 的 。 前 面 所 说 的 多 个 任务 并 行 不 悖 ， 互 不 依赖 ， 在 大 多 数 情况 下 只 是 一 种 美好 的 幻想 。 























首先 ， 多 个 线程 之 间 ， 存 在 负载 均衡 的 问题 ， 现 实 中 很 难 将 全 部 任务 等 分 给 每 个 线程 。 想 象 一 下 ， 如 果 存 在 10 个 线程 ， 一 个 线程 承担 了 90% 
的 任务 ，9 个 线程 承担 了 10% 的 任务 ， 整 体 的 效率 立刻 就 降 了 下 来 。 






































有 人 说 ， 怎 么 会 有 这 么 愚蠢 的 设计 呢 。 试 想 如 下 场景 : 你 需要 用 支持 10 个 并 发 线程 的 服务 器 去 计算 1~1010 以 内 的 所 有 素数 ， 要 怎么 设计 ? 
先进 入 脑海 的 第 一 反应 是 不 是 将 1~1010 这 个 范围 平均 分 成 10 份 ， 每 一 份 有 10? 个 数 ，10 个 线程 分 别 查找 范围 内 的 素数 ”这 就 是 糟糕 的 设计 ， 开 
管 每 个 线程 负责 的 范围 是 相同 的 ， 但 是 每 个 线程 的 负载 并 不 均匀 ， 因 为 判断 一 个 较 大 的 数 是 不 是 素数 ， 通 常 要 比 判 断 较 小 的 数 所 花费 的 时 间 更 

当然 这 个 例子 有 比较 妥善 的 解决 方案 ， 但 是 在 很 多 情况 下 ， 很 难 将 负载 均匀 地 分 配给 各 个 线程 。 
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其 次 ， 多 个 线程 的 任务 之 间 还 可 能 存在 顺序 依赖 的 关系 ， 一 个 线程 未 能 完成 某 些 操作 之 前 ， 其 他 线程 不 能 或 不 应 该 运行 。 


























多 个 线程 之 间 需 要 同步 。 想 象 如 下 场景 : 你 和 你 的 朋友 合租 一 套 公寓 ， 这 套 公 寓 只 有 1 个 卫生 间 。 当 你 朋友 正在 使 用 卫生 间 的 时 候 ， 你 就 无 
法 使 用 了 。 多 线程 也 会 过 到 类 似 的 问题 。 多 个 线程 生活 在 进程 地 址 空间 这 同一 个 屋 榴 下， 若 存 在 多 个 线程 操作 共享 资源 ， 则 需要 同步 ， 否 则 可 能 
网 结果 错误 、 数 据 结构 遭 到 破坏 甚至 是 程序 崩溃 等 后 果 。 因 此 多 线程 编程 中 存在 临界 区 的 概念 ， 临 界 区 的 代码 只 允许 一 个 线程 执行 ， 线 程 提 
供 了 锁 机 制 来 保护 临界 区 。 当 其 他 线程 来 到 临界 区 却 无 法 申请 到 锁 时 ， 就 可 能 陷入 阻塞 ， 不 再 处 于 可 执行 状态 ， 线 程 可 能 不 得 不 让 出 CPU 资源 。 
如 果 设 计 不 合理 ， 临 界 区 非常 多 ， 线 程 之 间 的 竞争 异常 激烈 ， 频 繁 地 上 下 文 切 换 也 会 导致 性 能 急剧 恶化 。 
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上 面 两 种 情况 的 存在 ， 决 定 了 多 线程 并 非 总 是 处 于 并 发 的 状态 ， 加 速 也 并 非 线性 的 。4 个 工作 线程 未 必 能 带 来 4 倍 的 效率 ， 加 速 比 取决 于 可 以 
串 行 执行 的 部 分 在 全 部 工作 中 所 占 的 比例 。 
















































































有 人 曾经 这 样 打 比 方 : 多 进程 属于 立体 交通 系统 ， 虽 然 造 价 高 ， 上 坡 下 坡 比较 耗 油 ， 但 是 堵车 少 ， 多 线程 属于 平面 交通 系统 ， 造 价 低 ， 但 是 
红绿灯 太 多 ， 老 堵车 。 个 人 觉得 这 个 比方 是 很 有 道理 的 。 
















































































多 线程 模型 的 复杂 度 更 是 不 容 小 裔 。 很 多 人 诉 病 多 线程 模型 ， 就 在 于 它 不 符合 人 的 心智 模型 。 俗 语 道 ， 一 心 不 可 两 用 ， 人 很 难 同时 控制 多 条 
走 走 停 停 ， 彼 此 又 有 交互 和 同步 的 控制 流 。 由 于 进程 调度 的 无 序 性 ， 严 格 来 说 多 线程 程序 的 每 次 执行 其 实 并 不 一 样 ， 很 难 穷 举 所 有 的 时 序 组 合 ， 
所 以 我 们 永远 无 法 宣称 多 线程 的 程序 经 过 了 充分 的 测试 。 在 某 些 特殊 时 序 的 条 件 下 ，bug 可 能 会 出 现 ， 这 种 bug 难 以 复 现 ， 而 且 难 以 排查 。 所 以 编 
程 时 ， 需 要 谨慎 地 设计 ， 以 确保 程序 能 够 在 所 有 的 时 序 条件 下 正常 运行 。 















































































































































对 于 多 线程 编程 ， 还 存在 四 大 陷阱 ， 一 不 小 心 就 可 能 落 入 陷阱 之 中 。 这 四 个 陷阱 分 别 是 : 


























: 死 锁 (Dead Lock) 


: 饿 死 〈Starvation) 


: 活 锁 (Live Lock) 





- 竞 态 条 件 (Race Condition) 





























客观 地 说 ， 多 线程 编程 的 难度 要 更 大 一 些 ， 需 要 程序 员 更 加 小 心 ， 更 加 谨慎 。 当 你 需要 使 用 多 线程 的 时 候 ， 一 定 要 花费 足够 的 时 间 小 心地 规 
划 每 个 线程 的 分 工 ， 尽 可 能 地 减少 线程 之 间 的 依赖 。 良 好 的 设计 ， 合 理 的 分 工 是 多 线程 编程 至 关 重 要 的 环节 。 若 初期 随意 地 设计 线程 的 分 工 ， 那 
么 在 最 后 ， 你 很 有 可 能 不 得 不 花费 大 量 的 时 间 来 优化 性 能 ， 定 位 bug， 甚 至 不 得 不 推倒 重 来 。 
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[1] 此 处 的 语序 混乱 是 故意 的 ， 上 暗 讽 由 于 线程 、 多 条 控制 流 、 时 序 失去 控制 ， 导 致 混乱 。 











7.2 ”进程 ID 和 线程 ID 
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在 Linux 中 ， 























的 线程 实现 是 Native POSIX Thread Library， 简 称 NPTL。 在 这 种 实现 下 ， 线 程 又 被 称 为 轻 量 级 进程 (Light Weighted 
Process) ， 每 一 个 用 户 态 的 线程 ， 在 内 核 之 中 都 对 应 一 个 调度 实体 ， 也 拥有 自己 的 进程 描述 符 (task_struct 结 构 体 〉。 

















































































































没有 线程 之 前 ， 一 个 进程 对 应 内 核 里 的 一 个 进程 描述 符 ， 对 应 一 个 进程 ID。 但 是 引入 了 线程 的 概念 之 后 ， 情 况 就 发 生 了 变化 ， 一 个 用 户 进 
程 下 管辖 N 个 用 户 态 线程 ， 每 个 线程 作为 一 个 独立 的 调度 实体 在 内 核 态 都 有 自己 的 进程 描述 符 ， 进 程 和 内 核 的 进程 描述 符 一 下 子 就 变 成 了 
的 关系 ，POSIX 标 准 又 要 求 进程 内 的 所 有 线程 调用 getpid 函 数 时 返回 相同 的 进程 ID。 如 何 解 决 上 述 问题 呢 ? 
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内 核 引 入 了 线程 组 (Thread Group ) 的 概念 。 





struct task struct {,.。 
Pid t pids 
pid t tgid 
struct task struct *group leader; 


struct list head thread group; 























多 线程 的 进程 ， 又 被 称 为 线程 组 ， 线 程 组 内 的 每 一 个 线程 在 内 核 之 中 都 存在 一 个 进程 描述 符 (task_struct) 与 之 对 应 。 进 程 描述 符 结构 体 中 
的 pid， 表 面 上 看 对 应 的 是 进程 ID， 其 实 不 然 ， 它 对 应 的 是 线程 ID;， 进程 描述 符 中 的 td， 含义 是 Thread Group ID， 该 值 对 应 的 是 用 户 层面 的 进程 
ID， 有 具体 见 表 7-3。 









































































































































表 7-3 ”线程 ID 和 进程 ID 的 值 





























本 节 介 绍 的 线程 ID， 不 同 于 后 面 会 讲 到 的 pthread_t 类 型 的 线程 D， 和 进程 ID 一 样 ， 线 程 ID 是 pid_t 凑 型 的 变量 ， 而 且 是 用 来 唯一 标识 线程 的 一 
个 整 型 变量 。 那 么 如 何 查看 一 个 线程 的 人 D 呢 ? 
































manu@manu-hacks:~$ ps - 


eLf 

UID PID PPID LWP C NLWP STIME TTY TIME CMD 

syslog 837 1 837 0 4 22:20 ? 00:00:00 rsyslogd 

syslog 837 FE 838 0 4 22:20 ? 00:00:00 rsyslogd 

SYS1og 837 于 839 0 4 22:20 ? 00:00:00 rsyslogd 
1 840 0 4 22:20 ? 00:00:00 rsyslogd 


syslog 837 








ps 命令 中 的 -L 选 项 ， 会 显示 出 线程 的 如 下 信息 。 




















:LWP: 线程 ID， 即 gettid () 系统 调用 的 返回 值 。 




















"NLWP: 线程 组 内 线程 的 个 数 。 











所 以 从 上 面 可 以 看 出 rsyslogd 进 程 是 多 线程 的 ， 进 程 了 p 为 837， 进 程 内 有 4 个 线程 ， 线 程 ID 分 别 为 837、838、839 和 840《〈 如 图 7-$ 所 示 ) 。 








已 知 某 进程 的 进程 ID， 该 如 何 查 看 该 进程 内 线程 的 个 数 及 





图 7-5 





procfs 在 task 下 会 给 进程 的 每 个 线程 建立 一 个 子 目录 ， 目 录 名 为 线程 ID。 





进程 ID 和 线程 ID (调度 域 ) 
































其 线程 ID 呢 ? 








其 实 可 以 通过 /proc/PID/aslv 目录 下 的 子 














录 来 查看 ， 如 下 。 











manu@manu-hacks:~$ 11 /proc/837/task/ 总 用 量 


0 
dr-xr-xr-x 6 syslog syslog 0 4 月 


16 22;32 ./ 
dr-xr-xr-x 9 syslog syslog 0 4 月 


16 22:20 .,/ 
dr-xr-xr-x 6 syslog syslog 0 4 月 


16 22:32 837/ 
dr-xr-xr-x 6 SYS1og syslog 0 4 月 


16 22:32 838/ 
dr-xr-xr-x 6 SYS1og syslog 0 4 月 


16 227532 B39/ 
dr-xr-xr-x 6 syslog syslog 0 4 月 


16 22:32 840/ 





























对 于 线程 ，Linux 提 供 了 gettid 系 统 调用 
确实 需要 获取 线程 DD， 可 以 采用 如 下 方法 : 


























江 
权 



































没有 将 该 系统 调用 封装 起 来 ， 再 开放 出 接口 来 供 程序 员 使 用 。 如 果 








回 其 线程 ID， 可 惜 的 是 glibc 




















#include <sys/syscall.h> 
int TID = syscall (SYS gettid); 








从 上 面 的 示例 来 看 ，rsyslogd 是 个 多 线程 的 进程 ， 进 程 ID 为 837， 下 面 














户 态 被 称 为 主线 程 (main thread) ， 在 内 核 

















ID，group_leader 指 针 则 指向 自身 ， 即 主线 程 的 进程 描述 符 ， 如 下 。 





有 一 个 线程 的 人 D 也 是 837， 这 不 是 巧合 。 线 程 组 内 的 第 一 个 线程 ， 在 用 
被 称 为 Group Leader。 内 核 在 创建 第 一 个 线程 时 ， 会 将 线程 组 ID 的 值 设置 成 第 一 个 线程 的 线程 



























































/* 线 程 组 


工 D 等 于 主线 程 的 


ID 


group_leader 指 向 自身 


wy 

E>tgid = p=->pildy 

p->group leader = p; 

INIT LIST HEAD(&p->thread group); 











所 以 可 以 看 到 ， 线 程 组 内 存在 一 个 线程 DD 等 于 进程 DD， 而 该 线程 即 为 线程 组 的 主线 程 。 
























































至 于 线程 组 其 他 线程 的 人 D 则 由 内 核 负责 分 配 ， 其 线程 组 DD 总 是 和 
线程 再 次 创建 的 线程 ， 都 是 这 样 。 





线程 的 线程 组 ID 一 致 ， 无 论 是 主线 程 直接 创建 的 线程 ， 还 是 创建 出 来 的 



































if (clone flags & CLONE _ THREAD) 
p->tgid = current->tgid; 
if (clone flags & CLONE THREAD) { 
p->group leader = current->group leader; 


list add tail rcul(g&p->thread group, &p->group leader->thread group); 
} 





























通过 group_leader 指 针 ， 每 个 线程 都 能 找到 主线 程 。 主 线程 存在 一 个 链表 头 ， 后 面 创 建 的 每 一 个 线程 者 

















会 链 入 到 该 双向 链表 中 。 




































































利用 上 述 的 结构 ， 每 个 线程 都 可 以 轻松 地 找到 其 线程 组 的 主线 程 〈 通 过 group_leader 指 针 ) ， 男 一 方 本 
地 遍历 其 所 有 的 组 内 线程 (通过 链表 ) 。 











， 通 过 线程 组 的 主线 程 ， 也 可 以 轻松 
























































需要 强调 的 一 点 是 ， 线 程 和 进程 不 一 样 ， 进 程 有 父 进 程 的 概念 ， 但 在 线程 组 



































有 面 ， 所 有 的 线程 都 是 对 等 的 关系 (如 图 7-6 所 示 )〉。 



































不 是 只 有 主线 程 才能 创建 线程 ， 被 创建 出 来 的 线程 同样 可 以 创建 线程 。 



































:不 存在 类 似 于 fork 函 数 那样 的 父子 关系 ， 大 家 都 归属 于 同一 个 线程 组 ， 进 程 ID 都 相等 ，group_leader 都 指向 3 





线程 ， 而 且 各 有 各 的 线程 ID。 














非 只 有 主线 程 才能 调用 pthread_ join 连接 其 他 线程 ， 同 一 线程 组 内 的 任意 线程 都 可 以 对 某 线程 执行 pthread join 函数 。 






































非 只 有 主线 程 才 能 调用 pthread detach 函 数 ， 其 实 任意 线程 都 可 以 对 同一 线程 组 内 的 线程 执行 分 离 操作 。 





同一 线程 组 的 线程 ， 没 有 层次 关系 


图 7-6 “线程 的 对 等 关系 


7.3 pthread 库 接口 介绍 























1995 年 ，POSIX.1c 标 准 对 POSIX 线 程 API 进 行 了 标准 化 ， 这 就 是 我 们 今天 看 到 的 pthread 库 的 接口 。 








这 些 接口 包括 线程 的 创建 、 退 出 、 取 消 和 分 离 ， 以 及 连接 已 经 终止 的 线程 ， 互 斥 量 ， 读 写 锁 ， 线 程 的 条 件 等 待 等 〈 如 表 7-4 所 示 ) 。 




















表 7-4 POSIX 线程 库 的 接 











POSIX 函数 函数 功能 描述 
pthread_ create 创建 一 个 线程 
pthread exit 退出 线程 
pthread self 获取 线程 ID 
pthread_ equal 检查 两 个 线程 ID 是 否 相 等 
pthread_join 等 竺 线程 退出 
pthread_detach 设置 线程 状态 为 分 离 状态 
pthread cancel 线程 的 取消 (将 于 第 8 草 介 绍 ) 


ee re 线程 退出 ， 清 理 函 数 注册 和 执行 














上 面 提 到 的 函数 列表 ， 是 pthread 的 基本 接口 ， 接 下 来 的 章节 ， 将 分 别 介绍 这 些 接口 。 











A 




















7.4 线程 的 创建 和 标识 





首先 要 介绍 的 接口 是 创建 线程 的 接口 ， 即 pthread_create 函 数 。 程 序 开始 启动 的 时 候 ， 产 生 的 进程 
只 有 一 个 线程 ， 我 们 称 之 为 主线 程 或 初始 线程 。 对 于 单线 程 的 进程 而 言 ， 只 存在 主线 程 一 个 线程 。 如 
果 想 在 主线 程 之 外 ， 再 创建 一 个 或 多 个 线程 ， 就 需要 用 到 这 个 接口 了 。 





























7.4.1 pthread _ create 函数 




















来 创建 线程 : 














pthread 库 提供 了 如 下 接 





#include <pthread.h> 

int pthread create (Pthread t *restrict thread, 
const pthread attr t *restrict attry 
void *(*start routine) (void*), 
void *restrict arg); 








pthread_create 函 数 的 第 一 个 参数 是 pthread t 类 型 的 指针 ， 线 程 创建 成 功 的 话 ， 会 将 分 配 的 线程 了 Dp 填 入 该 指针 指向 的 地 址 。 





使 用 该 值 作 为 线程 的 唯一 标识 。 








第 二 个 参数 是 pthread_attr {类 型 ， 通 过 该 参数 可 以 定制 线程 的 属 
要 求 ， 该 值 也 可 以 是 NULL， 表 示 采 用 默认 属性 。 




















A 
各 
bE 








三 个 参数 是 线程 需要 执行 
数 之 于 线程 ， 就 如 同 main 函 数 之 于 主线 程 。 

















个 参数 是 新 建 线程 执行 的 start_routine 函 数 的 入 参 。 





























需要 入 参 主线 程 在 调 


四 





新 建 线程 如 果 想 要 正常 工作 ， 则 可 能 
线程 。 


， 那 么 























的 函数 。 创 建 线程 ， 是 为 了 证 线程 执行 一 定 的 任务 。 


jpthread_create 的 时 候 ， 就 可 以 将 入 参 的 指针 放 入 入 


线程 的 后 续 操作 将 





性 ， 比 如 可 以 指定 新 建 线程 栈 的 大 小 、 调 度 策略 等 。 如 果 创 建 线程 无 特殊 的 





线程 创建 成 功 之 后 ， 该 线程 就 会 执行 start_routine 函 数 ， 该 函 





竺 用 


全 











个 参数 以 传递 给 新 建 




















如 果 线 程 的 执行 函数 start_routine 需 要 很 多 入 参 ， 


传递 一 个 指针 就 能 提供 





足够 的 信息 。 线 程 创建 者 《一 般 是 主线 程 )》 和 线程 约定 














一 个 结构 体 ， 创 建 者 便 把 信息 填 入 该 结构 体 ， 再 将 结构 体 的 指针 传递 给 























是 能 
子 进程 ， 子 进程 只 要 解析 该 结 





如 果 成 功 ， 则 pthread_create 返 回 0; 如 果 不 成 功 ， 则 pthread_create 返 回 


表 7-5 ”pthread_create 的 错误 码 及 


返 回 值 








EAGAIN 系统 资源 不 够 ， 

EINVAL 第 二 个 参数 attr 值 不 合法 

EPERM 有 合适 的 权限 来 设 
pthread_create 函 数 的 返回 情况 有 些 特殊 ， 通 常情 况 下 ， 函 数 调 用 失败 ， 



































为 返 区 


值 ， 而 不 是 一 个 负 值 。 











或 者 创建 线程 的 个 数 超过 


























构 体 ， 就 能 取出 需要 的 信息 。 





一 个 非 0 的 错误 码 。 常 见 的 错误 码 如 表 7-5 所 示 。 





述 














描 述 


寸 系 
a 


统 对 一 个 进程 中 线程 总 数 的 限制 


置 调度 策略 或 参数 





则 返 将 errno 作 





回 -1， 








目 设 置 errno。pthread create 函数 则 不 同 ， 它 会 





























void * thread worker (void *) 


Prinmtf(" 


I am thread worker” 


); 
pthread exit (NULL) 


pthread t tid; 

int ret = 0; 

ret = pthread create (gtid,NULL, gthread worker,NULL); 
if (ret != 0) /* 注意 此 处 ， 不 能 用 


ret < 0 作为 出 错 判断 


Ff 
{ 
/*ret is the errno*/ 
/*error handler*/ 


} 





7.4.2 ”线程 ID 及 进程 地 址 空间 布局 


pthread_create 函 数 ， 会 产生 一 个 线程 IDD， 存放 在 第 一 个 参数 指向 的 地 址 中 。 该 线程 ID 和 7.2 节 分 析 
的 线程 ID 是 一 回 事 吗 ? 


人 饮 三 | en 
答案 是 否定 的 。 














7.2 节 提 到 的 线程 ID， 属 于 进程 调度 的 范畴 。 因 为 线程 是 轻 量 级 进程 ， 是 操作 系统 调度 器 的 最 小 单 
位 ， 所 以 需要 一 个 数值 来 唯一 标识 该 线程 。 











pthread_create 函 数 产 生 并 记录 在 第 一 个 参数 指向 地 址 的 线程 ID 中 ， 属 于 NPTIL 线 程 库 的 范畴 ， 线 程 
库 的 后 续 操 作 ， 就 是 根据 该 线程 ID 来 操作 线程 的 。 




















线程 库 NPTL 提 供 了 pthread_ self 函数 ， 可 以 获取 到 线程 自身 的 ID: 


#include <pthread.h> 
pthread t pthread self (void); 











在 同一 个 线程 组 内 ， 线 程 库 提供 了 接口 ， 可 以 判断 两 个 线程 DD 是 否 对 应 着 同一 个 线程 : 











#include <pthread.h> 
int pthread equal (pthread t tl1, pthread t t2); 

















返回 值 是 0 的 时 候 ， 表 示 两 个 线程 是 同一 个 线程 ， 非 零 值 则 表示 不 是 同一 个 线程 。 





pthread_t 到 底 是 个 什么 样 的 数据 结构 呢 ? 因 为 POSIX 标 准 并 没有 限制 pthread_t 的 数据 类 型 ， 所 以 该 
类 型 取决 于 具体 实现 。 对 于 Linux 目 前 使 用 的 NPTL 实 现 而 言 ，pthread_t 类 型 的 线程 ID， 本 质 就 是 一 个 进 
程 地 址 空间 上 的 一 个 地 址 。 














是 时 候 看 一 下 进程 地 址 空间 的 布局 了 。 在 x86_64 平 台 上 ， 用 户 地 址 空间 约 为 128TB， 对 于 地 址 空间 
的 布局 ， 系 统 有 如 下 控制 选项 : 








cat /proc/sys/vm/legacy va layout 
0 








该 选项 影响 地 址 空间 的 布局 ， 主 要 是 影响 mmap 区 域 的 基地 址 位 置 ， 以 及 mmap 是 向 上 还 是 向 下 增 
长 。 如 果 该 值 为 1， 那 么 mmap 的 基地 址 mmap_base 变 小 〈 约 在 128T 的 三 分 之 一 处 ) ，mmap 区 域 从 低地 
址 向 高 地 址 扩展 。 如 果 该 值 为 0， 那 么 mmap 区 域 的 基地 址 在 栈 的 下 面 〈 约 在 128T 空 间 处 ) ，mmap 区 域 
从 高 地 址 向 低地 址 扩展 。 默 认 值 为 0， 布 局 如 图 7-7 所 示 。 




















内 核 空间 
0 
0200000S D600 00200 
AAA 随机 偏 移 区 AAAA 


主线 程 的 栈 


LALAAL 随机 仿 移 区 [AAALL 


堆 (heap ) 人 


LALL 瑚 机 篇 移 区 /1/1 










表 蛙 吝 隆 开 条 下 人 






未 初始 化 数据 段 (bss ) 





已 初始 化 数据 段 ( data ) 
代码 段 ( text ) 


图 7-7 多 线程 进程 的 地 址 空间 


可 以 通过 procfs 或 pmap 命 令 来 查看 进程 的 地 址 空间 的 情况 : 





pmap PID 





或 者 





cat /proc/PID/maps 





在 接近 128TB 的 巨大 地 址 空间 里 面 ， 代 码 段 、 已 初始 化 数据 段 、 未 初始 化 数据 段 ， 以 及 主线 程 的 
栈 ， 所 占用 的 空间 非常 小 ， 都 是 ECB、MB 这 个 数量 级 的 ， 如 下 : 





manuemanu-hacks:~$ pmap 3706 


3706: ./process map 

0000000000400000 4K r-x-- process map 
0000000000601000 4K r---- process map 
0000000000602000 4K rw--- process map.. 
00007ffdqq5f68000 5128K rw-—— [ Stack ]  /* 栈 在 


128T 位 置 附近 


yy 


由 于 主线 程 的 栈 大 小 并 不 是 固定 的 ， 要 在 运行 时 才能 确定 大 小 ‘上限 大 概 在 8MB 左 右 ) ， 因 此 ， 
在 栈 中 不 能 存在 巨大 的 局 部 变量 ， 另 外 编写 递归 函数 时 一 定 要 小 心 ， 递 归 不 能 太 深 ， 否 则 很 可 能 耗 尽 
栈 空间 。 


























如 下 面 的 例子 所 示 ， 无 尽 地 递归 ， 很 轻易 就 耗 尽 了 栈 的 空间 : 


int i = 0; 
void func () 


int buffer[256]; 
printf("i = S$d\n",i); 
下 让》 

func(); 


} 
int main() 
func(); 


Sleep (100); 
} 








上 面 代码 的 递归 永 不 停息 ， 每 次 递归 ， 都 会 消耗 约 IKB 〈256 个 int 型 为 IKB) 的 栈 空间 。 通 过 运行 
可 以 看 出 ， 主 线程 栈 最 大 也 就 在 8MB 左 右 : 





(核心 已 转 储 ) 


进程 地 址 空间 之 中 ， 最 大 的 两 块 地 址 空间 是 内 存 映 射 区 域 和 堆 。 堆 的 起 始 地 址 特别 低 ， 向 上 扩 
展 ，mmap 区 域 的 起 始 地 址 特别 高 ， 向 下 扩展 。 




















用 户 调用 pthread_create 消 数 时 ，glibc 首 先 要 为 线程 分 配 线程 栈 ， 而 线程 栈 的 位 置 就 落 在 mmap 区 
域 。glibc 会 调用 mmap 函 数 为 线程 分 配 栈 空间 。pthread_create 函 数 分 配 的 pthread t 类 型 的 线程 DD， 不 过 
是 分 配 出 来 的 空间 里 的 一 个 地 址 ， 更 确切 地 说 是 一 个 结构 体 的 指针 ， 如 图 7-8 所 示 。 





pthread ttid 


struct pthread 


线程 局 部 存储 





图 7-8 ”线程 DD 的 本 质 是 内 存 地 址 





创建 两 个 线程 ， 将 其 pthread_self() 的 返回 值 打印 出 来 ， 输 出 如 下 : 








address of tidq in thread-1 
address of tid in thread-2 


0x7f011cal2700 
0x7f011c211700 





线程 ID 是 进程 地 址 空间 内 的 一 个 地 址 ， 要 在 同一 个 线程 组 内 进行 线程 之 间 的 比较 才 有 意义 。 不 同 
线程 组 内 的 两 个 线程 ， 哪 怕 两 者 的 pthread t 值 是 一 样 的 ， 也 不 是 同一 个 线程 ， 这 是 显而易见 的 。 


























很 有 意思 的 一 点 是 ，pthread_t 关 型 的 线程 ID 很 有 可 能 会 被 复 用 。 在 满足 下 列 条 件 时 ， 线 程 ID 就 有 可 





1) 线程 退出 。 


2) 线程 组 的 其 他 线程 对 该 线程 执行 了 pthread_ join， 或 者 线程 退出 前 将 分 离 状 态 设置 为 已 分 离 。 





3) 再 次 调用 pthread_create 创 建 线程 。 





为 什么 pthread _t 类 型 的 线程 ID 会 被 复 用 ， 这 点 将 在 后 面 进 行 分 析 。 下 面 通 过 测试 来 证 明 一 下 : 





/* 省 略 了 


error handler*/ 

void* thread work (void* param) 

{ 
int TID = syscall (SYS gettiqd); 
printf ("thread-%d: gettid return %d\n",TID,TID); 
printf ("thread-%d: pthread self return %p\n",TID, (void *)pthread self()); 
printf ("thread-%d: I will exit now\n",TID); 加 
pthread exit (NULL); 
return NULL; 


int main(int argc ,char* argv[]) 


pthread t tid = 0; 





= pthread create(&tid,NULL,thread work,NULL); 
ret = pthread join(tiqd,NULL); 
ret = pthread create(&tid,NULL,thread work,NULL); 
ret = pthread join(tiqd,NULL); 
return 0; 








输出 结果 如 下 : 


thread-4158: gettid return 4158 

thread-4158: pthread self return 0x7f43a27d0700 
thread-4158: I will exit now 

thread-4159: gettid return 4159 

thread-4159: pthread self return 0x7f43a27d0700 
thread-4159: I will exit now 





从 输出 结果 上 看 ， 对 于 pthread t 类 型 的 线程 ID， 虽 然 在 同一 时 刻 不 会 存在 两 个 线程 的 了 p 值 相同 ， 但 
是 如 果 线 程 退 出 了 ， 重 新 创建 的 线程 很 可 能 复 用 了 同一 个 pthread_t 类 型 的 DD。 从 这 个 角度 看 ， 如 果 要 设 
计 调 试 日 志 ， 用 pthread t 类 型 的 线程 四 来 标识 进程 就 不 太 合 适 了 。 用 pid t 类 型 的 线程 DD 则 是 一 个 比较 不 
错 的 选择 。 














#include <sys/syscall.h> 
int TID = syscall (SYS gettid); 











采用 pid_t 类 型 的 线程 ID 来 唯一 标识 进程 有 以 下 优势 : 








返回 类 型 是 pid_t 炎 型， 进程 之 间 不 会 存在 重复 的 线程 ID， 而 且 不 同 线程 之 间 也 不 会 重复 ， 在 任意 
时 刻 都 是 全 局 唯一 的 值 。 




















proc 名 中 记录 了 线程 的 相关 信息 ， 可 以 方便 地 查看 /proc/pid/taslvtid 来 获取 线程 对 应 的 信息 。 


.ps 命令 提供 了 查看 线程 信息 的 -L 选 项 ， 可 以 通过 输出 中 的 LWP 和 NLWP， 来 查看 同一 个 线程 组 的 
线程 个 数 及 线程 ID 的 信息 。 














男 外 一 个 比较 有 意思 的 功能 是 我 们 可 以 给 线程 起 一 个 有 意义 的 名 字 ， 命 名 以 后 ， 既 可 以 从 procfs 中 
获取 到 线程 的 名 字 ， 也 可 以 从 ps 命令 中 得 到 线程 的 名 字 ， 这 样 就 可 以 更 好 地 辨识 不 同 的 线程 。 














Linux 提 供 了 prctl 系 统 调用 : 





#include <sys/prctl.h> 

int prctil(int option, unsigned long arg2, 
unsigned long arg3 , unsigned long arg4， 
unsigned long arg5) 





这 个 系统 调用 和 ioctl 非 常 类 似 ， 通 过 option 来 控制 系统 调用 的 行为 。 当 需要 给 线程 设 定名 字 的 时 
修 ， 只 需要 将 option 设 为 PR _ SET _ NAME， 同时 将 线程 的 名 字 作 为 arg2 传 递 给 prctl 系 统 调 用 即 可 ， 这 样 


就 能 给 线程 命名 了 。 











下 面 是 示例 代码 : 


void thread setnamev (const char* namefmt, va list args) 
{ 


char name[17]; 


vsnprintf (name sizeof (name), namefmt, args); 
prctl (PR_SET NAME, name, NULL, NULL, NULL); 
} 
void thread setname (const char* namefmt, ...) 
{ 
va_list args; 
va start (args, namefmt); 
thread setnamev (namefmt, args); 
va end (args); 
} 
thread setname ("BEAN-%d",num); 


这 里 共 创 建 了 四 个 线程 ， 按 照 调 用 pthread_create 的 顺序 ， 将 0、1、2、3 作 为 参数 传递 给 线程 ， 然 
后 调用 prctl 给 每 个 线程 起 名 字 : 分 别 为 BEAN-0、BEAN-1、BEAN-2 和 BEAN-3。 命 名 以 后 可 以 通过 ps 命 
令 来 查看 线程 的 名 字 : 








manu@manu-hacks:~$ ps -L -p 3454 

PID LWP TTY TIME CMD 

3454 3454 pts/0 00:00:00 pthread tid 

3454 3455 pts/0 00:00:00 BEAN-0 

3454 3456 pts/0 00:00:00 BEAN-1 

3454 3457 pts/0 00:00:00 BEAN-2 

3454 3458 pts/0 00:00:00 BEAN-3 
manu@manu-hacks:~$ cat /proc/3454/task/3457/status 


Name: BEAN-2 
State: S (sleeping) 
Tgid: 3454 








这 是 一 个 很 有 用 的 技巧 。 给 线程 命 了 名 ， 就 可 以 很 直观 地 区 分 各 个 线程 ， 尤 其 是 在 线程 比较 多 ， 
且 其 分 工 不 同 的 情况 下 。 











7.4.3 ”线程 创建 的 默认 属性 


线程 创建 的 第 二 个 参数 是 pthread_attr t 类 型 的 指针 ，pthread_attr_init 函 数 会 将 线程 的 属性 


Jmh 
un 





Ee 








置 成 默认 值 。 























pthread attz 七 Blt 
pthread attr init (gattr); 
































在 创建 线程 时 ， 传 递 重 置 过 的 属 怕 








E， 或 者 传递 NULL， 都 可 以 创建 














个 
































有 默认 属性 的 线程 ， 见 表 7-6。 


表 7-6 ”线程 的 属性 及 默认 值 
属 性 默 认 值 说 明 
进程 调度 相关 ，NPTL 实现 中 ,线程 只 支持 在 操作 系 
contentionscope | PTHREAD SCOPE SYSTEM 人 宅 相 关 Ssh 实现 中 ， 比 程 只 支持 在 操作 系统 
范围 内 竞争 CPU 资源 
detachstate PTHREAD CREATE JOINABLE 可 分 离 状 态 ， 详 情 请 见 pthread join 章节 ( 7.6.1 节 ) 
stackaddr NULL 不 指定 线程 栈 的 基 址 ， 由 系统 决定 栈 基 址 
stacksize 8196(KB) 默认 线程 栈 大 小 为 8MB (ulimit -s 查看 ) 
guardsize PAGESIZE 警戒 缓冲 区 
policy SCHED OTHER 进程 调度 相关 ， 调 度 策略 为 SCHED_ OTHER 
inheritsched PTHREAD INHERIT SCHED 进程 调度 相关 ， 继 承 局 动 进程 的 调度 策略 
手册 给 出 了 一 个 如 何 展示 线程 属性 的 例子 ， 若 你 需要 展示 线程 的 属性 ， 则 可 以 参考 手册 。 




















本 节 现 在 来 介绍 线程 栈 的 基地 址 和 


[0 大小。 默认 情况 下 ， 线 程 栈 的 大 小 为 8MB: 








manu@manu-hacks:~$ ulimit -s 
8192 








ea 


Wn 


线程 栈 














pthread_attr_getstack 函 数 可 以 返 
的 大 小 的 需要 。 




















一 个 线程 需要 分 配 83MB 左 右 的 栈 空间 ， 就 决定 了 不 可 能 无 限 


回 线程 栈 的 基地 址 和 栈 的 大 小 。 





上 上 


二 











也 创建 线程 ， 在 进程 
的 用 户 地 址 空间 决定 了 能 创建 线程 的 个 数 不 会 太 多 。 如 果 确 实 需要 很 多 的 线程 ， 可 


于 可 移植 性 的 考虑 不 建议 指定 线程 栈 的 基地 址 。 但 是 有 时 候 会 








修改 




































































也 址 空间 受 限 的 32 位 系统 里 尤为 如 此 。 在 32 位 系统 下 ，3GB 
以 调用 接口 来 调整 线程 栈 的 大 小 : 








#include <pthread.h> 
int pthread attr setstacksize (pthread attr t *attr, 
和 size t stacksize); 
int pthread attr getstacksize (pthread attr t *attr,size t *stacksize); 





7.5 线程 的 退出 


有 生 就 有 灭 ， 线 程 执行 完 任 务 ， 也 需要 终止 。 
下 面 的 三 种 方法 中 ， 线 程 会 终止 ， 但 是 进程 不 会 终止 《如 果 线 程 不 是 进程 组 里 的 最 后 一 个 线程 的 


























话 ) : 





创建 线程 时 的 start_ routine 函 数 执行 了 return， 并 且 返 回 指定 值 


:线程 调用 pthread exit。 











:其 他 线程 调用 了 pthread_cancel 疯 数 取 消 了 该 线程 ( 详 员 
如 果 线 程 组 中 的 任何 一 个 线程 调用 了 exit 函 数 ， 或 者 主线 程 在 main 函 数 中 执行 了 return 语 句 ， 那 么 整 











个 线程 组 内 的 所 有 线程 都 会 终止 。 


值得 注意 的 是 ，pthread_exit 和 线程 启动 函数 〈start routine) 执行 return 是 有 区 别 的 。 在 start_ routine 
退出 ， 而 return， 只 能 是 在 start_routine 函 数 


口 








中 调用 的 任何 层级 的 函数 执行 pthread_exit() 都 会 引发 线 和 
内 执行 才能 导致 线程 退出 。 


void* start routine (void* param) 


foo(); 
bar (); 
return NULL; 


} 
void foo() 


pthread exit (NULL); 


会 执行 了 。 





Hh ， 后面 的 bar 就 会 没有 机 





时 会 立刻 退 上 








如 果 foo 函 数 执行 了 pthread _exit 函 数 ， 则 线 和 
下 面 来 看 看 pthread_exit 函 数 的 定义 : 


#include <pthread.h> 
void pthread exit (void *value ptr); 





遗言 "。 线 程 组 内 的 其 他 线程 可 以 通过 调用 pthread join 函数 


遗言 。 如 果 线 程 退 + 





























value_ptr 是 一 个 指针 ， 存 放 线 程 的 “临终 
接收 这 个 地 址 ， 从 而 获取 到 退出 线程 的 临终 时 没有 什么 遗言 ， 则 可 以 直接 传递 


NULL 指 针 ， 如 下 所 示 : 

















pthread exit (NULL); 





但 是 这 里 有 一 个 问题 ， 束 是 不 能 将 遗言 存放 到 线程 的 局 部 变量 里 ， 因 为 如 果 用 户 写 的 线程 函数 退 
出 了 ， 线 程 函数 栈 上 的 局 部 变量 可 能 就 不 复 存在 了 ， 线 程 的 临终 遗言 也 就 无 法 被 接收 者 读 到 ， 示 例如 
证 5 
































void* thread work (voidqx param) 
{ 
int ret = -1; 
ret = whatever (); 
pthread exit (&ret); 
} 











上 述 用 法 是 一 种 典型 的 错误 用 法 ， 因 为 当 线程 退出 时 ， 线 程 栈 已 经 不 复 存 在 了 ， 上 面 的 ret 变 量 也 
已 经 无 法 访问 了 。 那 我 们 应 该 如 何 正 确 地 传递 返回 值 呢 ? 









































如果 是 int 型 的 变量 ， 则 可 以 使 用 "pthread_ exit ( (int*) ret) ; ” 
.使 用 全 局 变量 返回 


.将 返回 值 填 入 到 用 malloc 在 堆 上 分 配 的 空间 里 。 





:使 用 字符 串 常量 ， 如 pthread exit (“hello，world”) 。 








第 一 种 是 tricky 的 做 法 ， 我 们 将 返回 值 ret 进 行 强制 类 型 转换 ， 接 收 方 再 把 返回 值 强制 转换 成 int。 但 
是 不 推荐 使 用 这 种 方法 。 这 种 方法 虽然 是 奏效 的 ， 但 是 太 tricky， 而 且 C 标 准 没有 承诺 将 int 型 转 成 指针 
后 ， 再 从 指针 转 成 int 型 时 ， 数 据 一 直 保 持 不 变 。 


























第 二 种 方法 使 用 全 局 变量 ， 其 他 线程 调用 pthread join 时 也 可 见 这 个 变量 。 

















第 三 种 方法 是 用 malloc， 在 堆 上 分 配 空 间 ， 然 后 将 返回 值 填 入 其 中 。 因 为 堆 上 的 空间 不 会 随 着 线程 
的 退出 而 释放 ， 所 以 pthread_join 可 以 取出 返回 值 。 切 莫 忘 记 释放 该 空间 ， 和 否则 会 引起 内 存 泄漏 。 




















第 四 种 方法 之 所 以 可 行 ， 是 因为 字符 串 和 常量 有 静态 存储 的 生存 期 限 。 








传递 线程 的 返回 值 ， 除 了 pthread_exit 函 数 可 以 做 到 ， 线 程 的 启动 函数 〈start routine 函 数 ) return 也 
可 以 做 到 ， 两 者 的 数据 类 型 要 保持 一 致 ， 都 是 void* 类 型 。 这 也 解释 了 为 什么 线程 的 启动 函数 
start_routine 的 返回 值 总 是 void* 类 型 ， 如 下 : 














void pthread exit (void *retval); 
void * start routine (void *param) 


线程 退出 有 一 种 比较 有 意思 的 场景 ， 即 线程 组 的 其 他 线程 仍 在 执行 的 情况 下 ， 主 线程 却 调用 














pthread_exit 函 数 退 出 了 。 这 会 发 生 什 么 


hiall 
四 
届 











他 线程 则 不 受 影 


之 果 乡 


首先 要 说 明 的 是 这 不 是 常规 的 做 法 ， 但 是 如 果真 的 这 样 做 了 ， 那 么 主线 程 将 进入 僵尸 状态 ， 而 其 
响 ， 会 继续 执行 ， 如 下 。 第 4 











音 总 se 忆 . 
章 曾经 分 析 过 这 种 场景 。 

root@newtest-1:~# ps -eL |grep thread id 

62404 62404 pts/1 

62404 62405 pts/1 

62404 


00:00:00 thread id <defunct> 
00:00:00 thread id 
62406 pts/1 


00:00:00 thread id 


7.6 ”线程 的 连接 与 分 离 


7.6.1 ”线程 的 连接 














7.5 节 提 到 过 线程 退出 时 是 可 以 有 返回 值 的 ， 那 么 如 何 取 到 线程 退出 时 的 返回 值 呢 ? 












































线程 库 提供 了 pthread join 函数 ， 用 来 等 待 某 线程 的 退出 并 接收 它 的 返 臣 


























值 。 这 种 操作 被 称 为 连接 (joining) 。 





相关 函数 的 接口 定义 如 下 : 








#include <pthread.h> 
int pthread join(pthread t thread, void **retval); 











该 函数 第 一 个 参数 为 要 等 待 的 线程 的 线程 I， 第 二 个 参数 用 来 接收 返回 值 。 
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Ht， 可 得 到 如 下 两 种 情况 : 








:等 待 的 线程 尚未 退出 ， 那 么 pthread_join 的 调用 线程 就 会 陷入 阻塞 。 





:等 待 的 线程 已 经 退出 ， 那 么 pthread join 函数 会 将 线程 的 退 昌 














上 值 “void* 类 型 ) 存放 到 retval 指 针 指 向 的 位 









































线程 的 连接 (join) 操作 有 点 类 似 于 进程 等 待 子 进程 退出 的 等 待 《wait) 操作 ， 但 细 扣 




















想来 ， 还 是 有 不 同 之 处 : 
































第 一 点 不 同 之 处 是 进程 之 间 的 等 待 只 能 是 父 进程 等 待 子 进程 ， 而 线程 则 不 然 。 线 程 组 


可 以 对 另外 一 个 线程 执行 连接 (join) 操作 。 如 图 7-9 所 示 ， 线 程 F 一 样 可 以 连接 线程 A。 


























[内 的 成 员 是 对 等 的 关系 ， 只 要 是 在 一 个 线程 组 内 ， 就 











图 7-9 ”线程 的 连接 无 等 级 关系 



































第 二 点 不 同 之 处 是 进程 可 以 等 待 任 一 子 进程 的 退出 (用 下 
内 的 任 一 线程 ， 必 须 明确 指明 要 连接 的 线程 的 线程 ID。 


















































鲁 的 代码 不 难 做 到 〉 ， 但 是 线程 的 连接 操作 没有 类 似 的 接口 ， 即 不 能 连接 线程 组 











wait (&status); 
waitpid(-1,g&status, optioins) 





pthread join 不 能 连接 线程 组 内 任意 线程 的 做 法 ， 并 不 是 NPTIL 线 程 库 设计 上 的 瑕 症 ， 而 是 


程 ， 那 么 所 谓 的 任意 线程 就 会 包括 其 他 库 函 数 私自 创建 的 线程 ， 当 库 函 数 尝试 连接 (join) 私自 创建 的 线程 时 ， 发 现 
EINVAL 错 误 。 如 果 库 函数 需要 根据 返 世 


值 来 确定 接 下 来 的 流程 ， 这 就 会 引发 严重 的 问题 。 正 确 的 做 法 是 ， 连 接 已 入 
pthread join 函数 那样 。 























了 意 为 之 的 。 如 果 听 任 线程 连接 线程 组 内 的 任意 线 















































已 经 被 连接 过 了 ， 就 会 返回 


[线程 ID 的 那些 线程 ， 就 像 

























































































| 





下 面 来 分 析出 错 的 情况 ， 当 调用 失败 时 ， 和 pthread create 函数 一 样 ，errno 作 为 返 











可 值 返回 。 错 误 码 的 情况 见 表 7-7。 





表 7-7 ”pthread join 的 错误 码 和 说 明 


返回 值 


说 明 
ESRCH 传人 的 线程 ID 不 存在 ， 查 无 此 线程 
EINVAL 


线程 不 是 一 个 可 连接 (joinable) 的 线程 


返回 值 说 明 
EINVAL 已 经 有 其 他 线程 捷足先登 ， 连 接 目 标 线程 
EDEADLK 死 锁 ， 如 自己 连接 自己 ,或 者 A 连接 B，B 又 连接 A 









































pthread_ join 函数 之 所 以 能 够 判断 是 否 死 锁 和 连接 操作 是 否 被 其 他 线程 捷足先登 ， 是 因为 目标 线程 的 控制 结构 体 struct pthread 中 ， 存 在 如 下 成 
员 变 量 ， 记 录 了 该 线程 的 连接 者 。 























struct pthread *joinid; 





该 指针 存在 三 种 可 能 ， 如 下 。 






































-NULL: 线程 是 可 连接 的 ， 但 是 尚 没 有 其 他 线程 调用 pthread_join 来 连接 它 。 



























































指向 线程 自身 的 struct pthread: 表示 该 线程 属于 自我 了 断 型 ， 执 行 过 分 离 操作 ， 或 者 创建 线程 时 ， 设 置 的 分 离 属性 为 






































PTHREAD_CREATE_DETACHED， 一 旦 退出 ， 则 自动 释放 所 有 资源 ， 无 需 其 他 线程 来 连接 。 





























指向 线程 组 内 其 他 线程 的 struct pthread: 表示 joinid 对 应 的 线程 会 负责 连接 。 








妹 为 有 了 该 成 员 变 量 来 记录 线程 的 连接 者 ， 所 以 可 以 判断 如 下 场景 ， 如 图 7-10 所 示 。 














pthread_join 


pthread_join CR 和 A) 线程 B 


pthread_join 





图 7-10 ”可 能 返回 EDEADLK 的 场景 



































不 过 两 者 还 是 略 有 区 别 的 ， 第 一 种 场景 ， 线 程 A 连 接线 程 A，pthread join 函数 一 定 会 返回 EDEADLK。 但 是 第 二 种 场景 ， 大 部 分 情况 下 会 返 
可 EDEADLK， 不 过 也 有 例外 。 不 管 怎 样 ， 不 建议 两 个 线程 互相 连接 。 





















































~ 





如 果 两 个 线程 几乎 同时 对 处 于 可 连接 状态 的 线程 执行 连接 操作 会 怎么 样 








答案 是 只 有 一 个 线程 能 够 成 功 ， 男 一 个 则 返回 EINVAL。 





























NTPL 提 供 了 原子 性 的 保证 : 











(atomic compare and exchange bool _acq 


&pd->joined, self, NULL) 























:如 果 是 NULL， 则 设置 成 调用 线程 的 线程 DD，CAS 操 作 (Compare And Swap) 是 原子 操作 ， 不 可 分 市， 决定 了 只 有 一 个 线程 能 成 功 。 















































:如 果 joinid 不 是 NULL， 表 示 该 线程 已 经 被 别 的 线程 连接 了 ， 或 者 正 处 于 已 分 离 的 状态 ， 在 这 两 种 情况 下 ， 都 会 返回 EINVAL。 








7.6.2 ”为 什么 要 连接 退出 的 线程 





不 连接 已 经 退出 的 线程 会 怎么 样 ? 

















如 果 不 连接 已 经 退出 的 线程 ， 会 导致 资源 无 法 释放 。 所 谓 资 源 指 的 又 是 什么 呢 ? 





















































下 面 通过 一 个 测试 来 让 事实 说 话 。 测 试 模拟 下 面 两 种 情况 : 




















Hl 








主线 程 并 不 执行 连接 操作 ， 待 确定 创建 的 第 一 个 线程 退出 后 ， 再 创建 第 二 个 线程 。 





























主线 程 执行 连接 操作 ， 等 到 第 一 个 线程 退出 后 ， 再 创建 第 二 个 线程 。 





按照 时 间 线 来 发 展 ， 如 图 7-11 所 示 。 





pthread_create 








图 7-11 本 节 代 码 的 流程 示意 图 









































下 面 是 代码 部 分 ， 为 了 简化 程序 和 便于 理解 ， 使 用 sleep 操 作 来 确保 创建 的 第 一 个 线程 退出 后 ， 再 来 创建 第 二 个 线程 。 须 知 sleep 
并 不 是 同步 原 语 ， 在 真正 的 项 目 代码 中 ， 用 sleep 函 数 来 同步 线程 是 不 可 原谅 的 。 















































#define GNU SOURCE 

#include <stdio.h> 

#include <stdlib.h> 

#include <unistd.h> 

#include <pthread.h> 

#include <string.h> 

#include <errno.h> 

#include <sys/syscall.h> 

#include <sys/types.h> 

#define NR THREAD 1 

#define ERRBUF LEN 4096 

void* thread work (void* param) 
int TID = syscall (SYS gettid); 
printf ("thread-%d IN \n",TID); 
printf ("thread-%d pthread self return %p TTD (void*)pthread self ()); 
Sleep (60); 
printf ("thread-%d EXIT \n",TID); 
return NULL; 


int main(int argc ,char* argv[]) 


pthread t tid[NR THREAD]; 

pthread t tiqd 2[NR THREAD]; 

char errbuf [ERRBUF LEN]; 

int i, ret; 

for(i = 0; i < NR THREAD ; i++) 

{ 
ret = pthread create(&tid[i],NULL,thread work,NULL); 
if(ret != 0) 一 加 
{ 


} 


} 
#ifdef NO_JOIN 
Sleep (100);/*sleep 是 为 了 确保 线程 退出 之 后 ， 再 来 重新 创建 线程 


fprintf (stderr, "create thread failed ,return %d {%s)\n",ret,strerror r (ret,errbuf,sizeof (errbuf))); 


dh 

#else 
printf ("join thread Begin\n"); 
for(i = 0 ; i < NR THREAD; i++) 
{ 


pthread join(tid[i]l, NULL) 
} 
#endif 
for(i = 0 ;i < NR THREAD ; i++) 
{ 


ret = pthread create(&tid 2[i],NULL,thread work,NULL); 


if(ret != 0) 
{ 


fprintf (stderr, "create thread failed ,return %d (%s)\n",ret,strerror r (ret,errbuf,sizeof (errbuf))); 


} 


: 
Sleep (1000); 
exit (0); 








ml 





根据 编译 选项 NO_JOIN， 将 程序 编译 成 以 下 两 种 情况 : 








i 








-编译 加 上 -DNO_JOIN: 主线 不 执行 pthread_join， 主 线程 通过 sleep 足 够 的 时 间 ， 来 确保 第 一 个 线程 退出 以 后 ， 再 创建 第 二 个 线 




















:不 加 NO_JOIN 编 译 选 项 ， 主 线程 负责 连接 线程 ， 第 一 个 线程 退出 以 后 ， 再 来 创建 第 二 个 线程 








下 面 按照 编译 选项 ， 分 别 编 出 pthread_ no _ join 条 
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lpthread_has_join 两 个 程序 : 








gcc -0o pthread no join pthread join cmp.c -DNO_JOIN - 


lpthread 


gcc -oo pthread has join pthread join cmp.c 


-lpthread 








首先 说 说 pthread no_ join 的 情况 ， 当 创 妈 





[a 


了 第 一 个 线程 时 : 








manu@manu-hacks:~/code/me/thread$ ./pthread no join 


thread-12876 IN 


thread-12876 pthread self return 0x7fe0c842b700 





从 输出 可 以 看 到 ， 创 建 了 第 一 个 线程 


出 





， 其 线程 DD 为 12876， 


通过 pmap 和 procfs 可 以 看 到 系统 为 该 线程 分 配 了 8MB 的 地 址 空间 : 








manu@manu-hacks:~$ pmap 12875 

00007fe0c7c2b000 4K 一 一 一 一 一 [ anon 
00007fe0c7c2c000 8192K rw-—-= [ anon 
manu@manu-hacks:~$ cat /proc/12875/maps 


] 
lL 


7fe0c7c2b000-7fe0c7c2c000 ---p 00000000 00:00 07fe0c7c2c000-7fe0c842c000 


rw-p 00000000 00:00 0 


[stack:12876] 











当 线 程 12876 退 出 ， 创 建新 的 线程 时 : 











thread-12876 EXIT 
thread-13391 IN 


thread-13391 pthread self return 0x7fe0c7c2a700 























2 
此 时 查看 进程 的 地 址 空间 : 
00007fe0c742a000 === [ anon ] 
00007fe0c742b000 8192K rw--- [ anon ] 
00007fe0c7c2b000 村 了 守 [ anon ] 
00007fe0c7c2c000 8192K rw--- [ anon ] 


7fe0c742a000-7fe0c742b000 ---p 00000000 00:00 0 
7fe0c742b000-7fe0c7c2b000 rw-p 00000000 00:00 0 
7fe0c7c2b000-7fe0c7c2c000 ---p 00000000 00:00 07fe0c7c2c000-7fe0c842c000 


rw-p 00000000 00:00 0 


[stack:13391] 








从 上 面 的 输出 可 以 看 出 两 点 : 





1) 已 经 退出 的 线程 ， 其 空间 没有 被 释放 ， 仍 然 在 进程 的 地 址 空间 之 内 。 














2) 新 创建 的 线程 ， 没 有 复 用 刚才 退出 的 线程 的 地 址 空间 。 















































如 果 仅仅 是 情况 1 的 话 ， 尚 可 以 理解 ， 但 是 1 和 2 同时 发 生 ， 既 不 释放 ， 也 不 复 用 ， 这 就 不 能 忍 了 ， 因 为 这 已 经 属于 内 存 泄漏 了 。 


yy 





















































试想 如 下 场景 : FTP Server 采 用 thread per connection 的 模型 ， 每 接受 一 个 连接 就 创建 一 个 线程 为 之 服务 ， 服 务 结束 后 ， 连 接 断 开 ， 线 
程 退 出 。 但 线程 退出 了 ， 线 程 栈 消耗 的 空间 仍 不 能 释放 ， 不 能 复 用 ， 久 而 久之 ， 内 存 耗 尽 ， 再 也 不 能 创建 线程 ， 也 无 法 再 提供 FTP 服 


























































































































之 所 以 不 能 复 用 ， 原 因 就 在 于 没有 对 退出 的 线程 执行 连接 操作 。 下 面 来 看 一 下 主线 程 调用 pthread_ join 的 情况 : 




















manu@manu-hacks:~/code/me/thread$ ./pthread _ has join 
join thread Begin sD 
thread-14581 IN 

thread-14581 pthread self return 0x7f726020f700 
thread-14581 EXIT 

thread-14871 IN 

thread-14871 pthread self return 0x7f726020f700 
thread-14871 EXIT 























两 次 创建 的 线程 ，pthread 类 型 的 线程 四 完全 相同 ， 看 起 来 好 像 前 面 退 





























的 栈 空间 被 复 用 了 ， 事 实 也 的 确 如 此 : 








(Er 



































manu@manu-hacks:~$ cat /proc/14580/maps 
7f725fa0f000-7f725fal0000 ---p 00000000 00:00 0 
7f725fal0000-7f7260210000 rw-p 00000000 00:00 0 [stack:14581] 














12581 退 出 后 ， 线 程 栈 被 后 创建 的 线程 复 用 了 : 














manu@manu-hacks:~$ cat /proc/14580/maps 
7f725fa0f000-7f725fal0000 ---p 00000000 00:00 0 
7f725fal0000-7f7260210000 rw-p 00000000 00:00 0 [stack:14871] 












































通过 前 面 的 比较 ， 可 以 看 出 执行 连接 操作 的 重要 性 :， 如果 不 执行 连接 操作 ， 线 程 的 资源 就 不 能 被 释放 ， 也 不 能 被 复 用 ， 这 就 造成 
资源 的 泄漏 。 





















































当 线 程 组 内 的 其 他 线程 调用 pthread join 连接 退出 线程 时 ， 内 部 会 调用 _free_tcb 函 数 ， 该 函数 会 负责 释放 退出 线程 的 资源 。 
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直 得 一 提 的 是 ， 纵 然 调 用 了 pthread join， 也 并 没有 立即 调用 munmap 来 释放 掉 退 出 线程 的 栈 ， 它 们 是 被 后 建 的 线程 复 用 了 ， 这 是 
NPTI 线 程 库 的 设计 。 释 放 线程 资源 的 时 候 ，NPTL 认 为 进程 可 能 再 次 创建 线程 ， 而 频繁 地 munmap 和 mmap 会 影响 性 能 ， 所 以 NTPL 将 该 
栈 缓存 起 来 ， 放 到 一 个 链表 之 中 ， 如 果 有 新 的 创建 线程 的 请 求 ，NPTL 会 首先 在 栈 缓存 链表 中 寻找 空间 合适 的 栈 ， 有 的 话 ， 直 接 将 该 
栈 分 配给 新 创建 的 线程 。 



































































































































7.6.3 ”线程 的 分 离 




















默认 情况 下 ， 新 创建 的 线程 处 于 可 连接 (Joinable〉 的 状态 ， 可 连接 状态 的 线程 退出 后 ， 需 要 对 其 执行 连接 操作 ， 否 则 线程 资源 无 法 释放 ， 














从 而 造成 资源 泄漏 。 
































如 果 其 他 线程 并 不 关心 线程 的 返回 值 ， 那 么 连接 操作 就 会 变 成 一 种 负担 : 你 不 需要 它 ， 但 是 你 不 去 执行 连接 操作 又 会 造成 资源 泄漏 。 这 时 














候 你 需要 的 东西 只 是 : 线程 退出 时 ， 系 统 自动 将 线程 相关 的 资源 释放 掉 ， 无 须 等 待 连接 。 
































NPTIL 提 供 了 pthread detach 函 数 来 将 线程 设置 成 已 分 离 〈detached) 的 状态 ， 如 果 线 程 处 了 
线程 的 资源 ， 如 下 : 


nm 














已 分 离 的 状态 ， 那 么 线程 退出 时 ， 系 统 将 负责 回 








#include <pthread.h> 
int pthread detach (pthread t thread); 














可 以 是 线程 组 内 其 他 线程 对 目标 线程 进行 分 离 ， 也 可 以 是 线程 自己 执行 pthread_detach 函 数 ， 将 自身 设置 成 已 分 离 的 状态 ， 如 下 : 
































pthread detach (pthread self ()) 














线程 的 状态 之 中 ， 可 连接 状态 和 已 分 离 状态 是 冲突 的 ， 一 个 线程 不 能 既是 可 连接 的 ， 又 是 已 分 离 的 。 因 此 ， 如 果 线 程 处 于 已 分 离 的 状态 ， 














其 他 线程 尝试 连接 线程 时 ， 会 返回 EINVAL 错 误 。 














pthread_detach 出 错 的 情况 见 表 7-8 所 示 。 


表 7-8 ”pthread_detach 的 错误 码 和 说 明 











返 回 值 说 明 
ESRCH 传人 的 线程 ID 不 存在 ， 查 无 此 线程 
EINVAL 线程 不 是 一 个 可 连接 (joinable) 的 线程 ， 已 经 处 于 已 分 离 状态 








需要 强调 的 是 ， 不 要 误解 已 分 离 状态 的 内 涵 。 所 谓 已 分 离 ， 并 不 是 指 线程 失去 控制 ， 不 归 








线程 组 管理 ， 而 是 指 线程 退出 后 ， 系 统 会 自动 释 














放 线 程 资源 。 若 线程 组 内 的 任意 线程 执行 了 exit 函 数 ， 即 使 是 已 分 离 的 线程 ， 也 仍然 会 受到 影响 ， 一 并 退出 。 





























将 线程 设置 成 已 分 离 状 态 ， 并 非 只 有 pthread_detach 一 种 方法 。 另 一 种 方法 是 在 创建 线程 时 ， 将 线程 的 属性 设 定 为 已 分 离 : 























#include <pthread.h> 
int pthread attr setdetachstate (pthread attr t *attr,int detachstate); 
int pthread attr getdetachstate (pthread attr t *attr,int *detachstate); 




















其 中 detachstate 的 可 能 值 如 表 7-9 所 示 。 
表 7-9 分离 状态 的 合法 值 
分 离 状态 的 可 选 值 
PTHREAD CREATE JOINABLE 默认 情况 ， 表 示 创 
PTHREAD CREATE DETACHED 表示 创建 出 来 的 线 

















说 明 
建 出 来 的 线程 会 处 于 可 连接 的 状态 
程 ， 会 处 于 已 分 离 的 状态 


有 了 这 个 ， 如 果 确 实 不 关心 线程 的 返回 值 ， 可 以 在 创建 线程 之 初 ， 就 指定 其 分 离 属性 为 PTHREAD_CREATE _DETACHED。 





7 了 7 互 太 量 


7.7.1 ”为 什么 需要 互 斥 量 














大 部 分 情况 下 ， 线 程 使 用 的 数据 都 是 局 部 变量 ， 变 量 的 地 址 在 线程 栈 空 间 内 ， 这 种 情况 下 ， 变 量 
归属 于 单个 线程 ， 其 他 线程 无 法 获取 到 这 种 变量 。 


如 果 所 有 的 变量 都 是 如 此 ， 将 会 省 去 无 数 的 麻烦 。 但 实际 的 情况 是 ， 很 多 变量 都 是 多 个 线程 共享 
的 ， 这 样 的 变量 称 为 共享 变量 (shared variable) 。 可 以 通过 数据 的 共享 ， 完 成 多 个 线程 之 间 的 交互 。 











但 是 多 个 线程 并 发 地 操作 共享 变量 ， 会 带 来 一 些 问题 。 
下 面 来 看 一 个 例子 ， 如 图 7-12 所 示 。 
Thread A Thread B 


EE 2 7 RE 了 }) 
guobal ‘Critt++t global cnt++ 





Thread C Thread D 
FE 2 for ( ;;) 
global entitt global, cnet 


图 7-12 ”多 线程 操作 全 局 变量 


如 果 存 在 4 个 线程 ， 不 加 任何 同步 措施 ， 共 同 操作 一 个 全 局 变量 global_cnt， 假 设 每 个 线程 执行 1000 
万 次 自 加 操作 ， 那 么 会 发 生 什 么 事情 呢 ? 4 个 线程 结束 的 时 候 ，8global_cnt 等 于 几 ? 


这 个 问题 看 起 来 是 小 学 题目 ， 当 然 是 4000 万 ， 但 实际 结果 又 如 何 呢 ? 





define _GNU_SOURCE 
include <stdio.h> 
include <stdlib.h> 





# 
# 
include <unistd.h> 
#include <pthread.h> 
include <string.h> 
#include <errno.h> 

include <sys/types.h> 
#define LOOP TIMES 10000000 
define NR THREAD 4 
pthread rwlock t rwlock; 
int global cnt = 0; 
void* thread work (void* Param) 

{ 

主 从 羽 。 入 证 
pthread rwlock rdlock(&rwlock); 

















for(E 一 0 7 主 和 GOooP TIMES; i++ ) 
global cnt++; 


pthread rwlock unlock(&rwlock); 
return NULL; 


main(int argc ,char* argv[]) 


pthread - t tid[NR THREAD]; 

char err buf{[1024]; 

pi ol Wh 

ret = pthread rwilock init(&rwilock,NULL); 
if (ret) 

{ 





fprintf (stderr,"init rw lock failed ($s) \n", strerror r(ret,err buf, sizeof (err buf))); 
及 宇 七 必 ) 
} 
pthread rwlock wrlock (&rwlock); 
for(i = 0 ; i < NR THREAD ; i++) 
{ 
ret = pthread create(&tid[i],NULL,thread work,NULL); 
ifl(ret != 0) 
{ 
fprintf (stderr,"create thread failed ,return %d ($s)\n", 
ret,strerror rl(ret,err buf,sizeof (err buf))); 
} 
} 
pthread rwlock unlock(&rwlock); 
for(i = 0 ; i < NR THREAD; I++) 
{ 


} 
pthread rwlock CS 


pthread join(tid[i],NULL); 


printf ("thread num : Sd\n",NR THREAD); 

printf ("loops per thread : $d\n",LOOP TIMES); 

printf ("expect result : Sd\n",LOOP TIMES*NR THREAD); 
printf("actual result : Sd\n",global cnt); 

exit (0); 











上 面 的 代码 中 ， 引 入 了 读 写 锁 ， 来 确保 线程 位 于 同一 起 跑 线 ， 同 时 开始 执行 自 加 操作 ， 不 受 线程 














创建 
申请 








先后 顺序 的 影响 。 创 建 4 个 线程 之 前 ， 主 线程 先 占 住 读 写 锁 的 写 锁 ， 任 一 线程 创建 好 了 之 后 ， 要 先 








读 锁 ， 申 请 成 功 方 能 执行 global cntt+， 但 是 写 锁 已 经 被 主线 程 占据 ， 所 以 无 法 执行 。 待 4 个 线程 都 





创建 成 功 后 ， 主 线程 会 释放 写 锁 ， 从 而 保证 4 个 线程 一 起 执行 。 











执行 结果 又 如 何 呢 ?来 看 看 : 








thread num : 4 
loops per thread : 10000000 
expect result : 40000000 
actual result TLLELSLSG 
结果 并 不 是 期 待 的 4000 万 ， 而 是 11115156， 一 个 很 奇怪 的 数字 。 而 且 每 次 执行 ， 最 后 的 结果 都 不 


相同 。 

















为 什么 无 法 获得 正确 的 结果 ? 








看 一 下 汇编 代码 ， 先 通过 如 下 指令 读 取 到 汇编 代码 : 


objdump -d pthread no sync > pthread no_sync.objdump 


然后 在 汇编 代码 中 取出 global_cntt+ 这 部 分 代码 相关 的 汇编 代码 ， 就 是 如 下 指令 


40098c : 8b 05 la 07 20 00 mov Ox20071a (Srip),%eax # 6010ac <global cnt> 
400992: 83:. -560° :01 add $0x1, Seax 
400995 : 39 05. 11 07 .20 00 mov Seax, Ox200711 (Srip) # 6010ac <global cnt> 











++ 操 作 ， 并 不 是 一 个 原子 操作 (atomic operation) ， 而 是 对 应 了 如 下 三 条 汇编 指令 。 


.Load: 将 共享 变量 global_cnt 从 内 存 加 载 进 寄存 器 ， 简 称 L。 





:Update: 更 新 寄存 器 里 面 的 global _cnt 值 ， 执 行 加 1 操作 ， 简 称 U。 











Store: 将 新 的 值 ， 从 寄存 器 写 回 到 共享 变量 global_cnt 的 内 存 地 址 ， 简 称 为 S。 





将 上 述 情况 用 伪 代 码 表示 ， 就 是 如 下 情况 : 








工 操作 : 


register = global cnt 
操作: 


register = register + 1 
S 操 作 : 


global cnt = register 





以 两 个 线程 为 例 ， 如 果 两 个 线程 的 执行 如 图 7-13 所 示 ， 就 会 引发 结果 不 一 致 : 执行 了 两 次 ++ 操 
作 ， 最 终 的 结果 却 只 加 了 1。 





线程 A 线程 B global_cnt 


所 一 一 一 一 一 送 国 村 


图 7-13 ”多 线程 操作 全 局 变量 结果 出 错 的 原因 








上 面 的 例子 表明 ， 应 该 避免 多 个 线程 同时 操作 共享 变量 ， 对 于 共享 变量 的 访问 ， 包 括 读 取 和 写 
入 ， 都 必须 被 限制 为 每 次 只 有 一 个 线程 来 执行 。 


用 更 详细 的 语言 来 描述 下 ， 解 决 方案 需要 能 够 做 到 以 下 三 点 。 





1) 代码 必须 要 有 互 斥 的 行为 : 当 一 个 线程 正在 临界 区 中 执行 时 ， 不 允许 其 他 线程 进入 该 临界 区 

2) 如 果 多 个 线程 同时 要 求 执行 临界 区 的 代码 ， 并 且 当 前 临界 区 并 没有 线程 在 执行 ， 那 么 只 能 允许 
一 个 线程 进入 该 临界 区 。 

3) 如 果 线 程 不 在 临界 区 中 执行 ， 那 么 该 线程 不 能 阻止 其 他 线程 进入 临界 区 。 


上 面 说 了 这 么 多 ， 本 质 其 实 就 是 一 句 话 ， 我 们 需要 一 把 锁 (如 图 7-14 所 示 )〉。 


非 临 界 区 ， 可 以 并 发 执行 的 代码 区 域 


临界 区 ， 只 人 允许 一 个 线程 执行 ， 
不 允许 多 个 线程 同时 执行 


非 临界 区 ， 可 以 并 发 执行 的 代码 区 域 





图 7-14 ”用 锁 来 保护 临界 区 


锁 是 一 个 很 普遍 的 需求 ， 当 然 用 户 可 以 自行 实现 锁 来 保护 临界 区 。 但 是 实现 一 个 正确 并 且 高 效 的 
锁 非 常 困 难 。 纵 然 抛 下 高 效 不 谈 ， 证 用 户 从 零 开 始 实现 一 个 正确 的 锁 也 并 不 容易 。 正 是 因为 这 种 需求 
具有 普遍 性 ， 所 以 Linux 提 供 了 互 斥 量 。 








7.7.2 互 斥 量 的 接口 


1. 互 斥 量 的 初始 化 








互 斥 量 采 用 的 是 英文 mutual exclusive (互相 排斥 之 意 ) 的 缩写 ， 即 mutex。 


正确 地 使 用 互 斥 量 来 保护 共享 数据 ， 首 先 要 定义 和 初始 化 互 斥 量 。POSIX 提 供 了 两 种 初始 化 互 斥 量 
的 方法 。 











第 一 种 方法 是 将 PTHREAD MUTEX INITIALIZER 赋 值 给 定义 的 互 斥 量 ， 如 下 : 








#include <pthread.h> 
pthread mutex t mutex = PTHREAD MUTEX INITIALIZER; 























如 果 互 斥 量 是 动态 分 配 的， 或 者 需要 设 定 互 斥 量 的 属性 ， 那 么 上 面 静态 初始 化 的 方法 就 不 适用 
了 ，NPTL 提 供 了 另外 的 函数 pthread_mutex_init《〈) 对 互 斥 量 进行 动态 的 初始 化 : 























int pthread mutex init (pthread mutex t *restrict mutex, 
const pthread mutexattr t *restrict attr); 














第 二 个 pthread_mutexattr 人 指针 的 入 参 ， 是 用 来 设 定 互 斥 量 的 属性 的 。 大 部 分 情况 下 ， 并 不 需要 设置 
互 斥 量 的 属性 ， 传 递 NULL 即 可 ， 表 示 使 用 互 斥 量 的 默认 属性 。 








调用 pthread mutex init () 之 后 ， 互 斥 量 处 于 没有 加 锁 的 状态 。 


2. 互 斥 量 的 销毁 


























在 确定 不 再 需要 互 斥 量 的 时 候 ， 就 要 销毁 它 。 在 销毁 之 前 ， 有 三 点 需要 注意 : 








.使 用 PTHREAD MUTEX INITIALIZER 初 始 化 的 互 斥 量 无 须 销 毁 。 














不 要 销毁 一 个 已 加 锁 的 互 斥 量 ， 或 者 是 真正 配合 条 件 变量 使 用 的 互 斥 量 。 








已 经 销毁 的 互 太 量 ， 要 确保 后 面 不 会 有 线程 再 答 试 加 锁 。 








销毁 互 斥 量 的 接口 如 下 : 


int pthread mutex destroy(pthread mutex 七 *mutex); 





当 互 斥 量 处 于 已 加 锁 的 状态 ， 或 者 正在 和 条 件 变量 配合 使 用 ， 调 用 pthread_mutex_destroy 函 数 会 返 
回 EBUSY 错 误 码 。 





3. 互 斥 量 的 加 锁 和 解锁 











POS 芭 提供 了 如 下 接口 : 





int pthread mutex lock(pthread mutex 七 *mutex); 
int pthread mutex trylock (pthread 1 mutex t *mutex); 
int pthread mutex unlock (pthread mutex t *mutex); 


在 调用 pthread_ lock《〈) 的 时 候 ， 可 能 会 遭遇 以 下 几 种 情况 : 





互 斥 量 处 于 未 锁定 的 状态 ， 该 函数 会 将 互 斥 量 锁定 ， 同 时 返回 成 功 。 














.发 起 函数 调用 时 ， 其 他 线程 已 锁定 互 斥 量 ， 或 者 存在 其 他 线程 同时 申请 互 斥 量 ， 但 没有 竞争 到 互 
斥 量 ， 那 么 pthread lock 〈) 调用 会 陷入 阻塞 ， 等 待 互 斥 量 解锁 。 








企 等 待 的 过 程 中 ， 如 果 互 斥 量 持 有 线程 解锁 互 太 量 ， 可 能 会 发 生 如 下 事件 : 








函数 调用 线程 是 唯一 等 待 者， 获得 互 斥 量 ， 成 功 返 回 


函数 调用 线程 不 是 唯一 等 待 者， 但 成 功 获得 互 矿 量 ， 返 回 


函数 调用 线程 不 是 唯一 等 待 者 ， 没 能 获得 互 斥 量 ， 继 续 阻 塞 ， 等 待 下 一 轮 。 





:如 果 在 调用 pthread lock《〈) 线程 时 ， 之 前 已 经 调用 过 pthread lock〈) 且 已 经 持 有 了 互 斥 量 ， 则 根 
据 互 斥 锁 的 类 型 ， 存 在 以 下 三 种 可 能 





.PTHREAD MUTEX NORMAL: 这 是 默认 类 型 的 互 斥 锁 ， 这 种 情况 下 会 发 生死 锁 ， 调 用 线程 永 
入 阻塞 ， 线 程 组 的 其 他 线程 也 无 法 申请 到 该 互 斥 量 。 





:PTHREAD_MUTEX _ERRORCHECK: 第 二 次 调用 pthread_mutex lock 函数 时 返回 EDEADLK。 


PTHREAD_ MUTEX RECURSIVE: 这 种 类 型 的 互 斥 锁 内 部 维护 有 引用 计数 ， 人 允许 锁 的 持 有 者 再 
次 调用 加 锁 操 作 。 








有 了 互 斥 量 ， 重 新 运行 7.7.1 节 的 程序 ， 将 global_cnttr+ 改 写成 : 








pthread mutex lock(&mutex); 
global cnt++; 
pthread | mutex lock(&mutex); 


使 用 互 斥 量 之 后 ， 程 序 获取 了 正确 的 执行 结 





thread num : 4 
loops per thread : 10000000 
expect result : 40000000 


actual result : 40000000 





7.7.3 ”临界 区 的 大 小 





现在 ， 我 们 已 经 意识 到 需要 用 锁 来 保护 共享 变量 。 不 过 还 有 男 一 个 需要 注意 的 事项 ， 即 合理 地 设 定 临 界 区 
的 范围 。 


第 一 临界 区 的 范围 不 能 太 小 ， 如 果 太 小 ， 可 能 起 不 到 保护 的 目的 。 考 虑 如 下 场景 ， 如 果 哈 希 表 中 不 存在 茶 
元 素 ， 那 么 向 哈 希 表 中 插入 茶 元 素 ， 代 码 如 下 : 








if(!htable_contain (nashtablevelem.key) ) 
{ 


pthread mutex lock(&mutex); 
htable insert (hashtable, &elem); 
pthread mutex lock(&mutex); 

} 











表面 上 看 ， 共 享 变 量 hashtable 得 到 了 保护 ， 在 择 入 时 有 和 锁 保护 ， 但 是 结果 却 不 是 我 们 想 要 的 。 上 面 的 程序 
不 希望 哈 希 表 中 有 重复 的 元 素 ， 但 是 其 临界 区 太 小 ， 多 线程 条 件 下 可 能 达 不 到 预 设 的 效果 。 











如 果 时 序 如 图 7-15 所 示 ， 那 么 就 会 有 重复 的 元 素 被 插入 喻 希 表 中 ， 没 有 达到 最 初 的 目的 。 完 其 原因 ， 就 是 
临界 区 小 了 ， 没 有 将 判断 部 分 加 入 临界 区 以 内 。 








临界 区 也 不 能 太 大 ， 临 界 区 的 代码 不 能 并 发 ， 如 果 临 界 区 太 大 ， 就 无 法 充分 利用 多 处 理 器 发 挥 多 线程 的 优 
势 。 对 于 被 互 斥 量 保护 的 临界 区 内 的 代码 ， 一 定 要 好 好 审视 ， 不 要 将 不 相干 的 《特别 是 可 能 陷入 阻塞 的 ) 代码 
放 入 临界 区 内 执行 。 








线程 A 线程 B 








喻 希 表 中 是 否 包含 key 哈 希 表 中 是 否 包含 key 








陷 人 幅 塞 





>; 解除 阻塞 
Y 


将 元 素 搬入 哈 布 表 





<-------------- 路 国 则 ------------------ 


解锁 互 斥 量 


图 7-15 ”临界 区 太 小 ， 未 能 解决 竞争 ， 重 复 插 入 了 某 元 素 


[hl 





7.7.4 互 斥 量 的 性 能 



































还 是 以 前 面 的 例子 为 例 进行 说 明 ，4 个 线程 分 别 对 全 局 变量 累加 1000 万 次 ， 使 用 互 斥 量 版 本 的 程序 和 不 使 用 互 斥 量 的 版 本 相 比 ， 会 消耗 更 多 
的 时 间 ， 如 表 7-10 所 示 。 


























表 7-10 “加 锁 版 本 和 无 锁 版 本 的 性 能 比较 


无 互 斥 量 的 版 本 使 用 互 斥 量 的 版 本 


11.433s 


























互 斥 量 版 本 需要 消耗 更 长 的 时 间 ， 其 原因 有 以 下 三 点 : 

















1) 对 互 斥 量 的 加 锁 和 解锁 操作 ， 本 身 有 一 定 的 开销 。 








2) 临界 区 的 代码 不 能 并 发 执行 。 





























3) 进入 临界 区 的 次 数 过 于 频繁 ， 线 程 之 间 对 临界 区 的 争夺 太 过 激烈 ， 若 线程 竞争 互 斥 量 失败 ， 就 会 陷入 阻塞 ， 让 出 CPU， 上 所 以 执行 上 下 文 
切换 的 次 数 要 远 远 多 于 不 使 用 互 斥 量 的 版 本 。 






































看 到 这 个 结果 ， 又 有 一 个 疑问 涌 上 心头 ， 互 斥 量 的 性 能 如 何 ? 

































































Linux 下 ， 互 斥 量 的 实现 采用 了 futex (fast user space mutex) 机 制 。 传 统 的 同步 手段 ， 进 入 临界 区 之 前 会 申请 锁 ， 而 此 时 不 得 不 执行 系统 调 
]， 查 看 是 否 存在 竞争 ; 当 离 开 临 界 区 释放 锁 的 时 候 ， 需 要 再 次 执行 系统 调用 ， 查 看 是 否 需要 唤醒 正在 等 待 锁 的 进程 。 但 是 在 竞争 并 不 激烈 的 1 
况 下 ， 加 锁 和 解锁 的 过 程 中 可 能 会 出 现 以 下 两 种 情况 : 




















































































































“申请 锁 时 ， 执 行 系统 调用 ， 从 用 户 模式 进入 内 核 模 式 ， 却 发 现 并 无 竞争 。 

































































释放 锁 时 ， 执 行 系统 调用 ， 从 用 户 模 式 进 入 内 核 模式 ， 尝 试 唤醒 正在 等 待 锁 的 进程 ， 却 发 现 并 没有 进程 正在 等 待 锁 的 释放 。 


















































考虑 到 系统 调用 的 开销 ， 这 两 种 情况 耗资 靡 费 ， 却 劳 而 无 功 。 




















futex 机 制 的 出 现 有 效 地 解决 了 这 两 个 问题 。futex 的 全 称 是 fast userspace mutex， 中 文 名 为 快速 用 户 空 间 互 斥 体 ， 它 是 一 种 用 户 态 和 内 核 态 协同 
工作 的 同步 机 制 。sglibc 使 用 内 核 提 供 的 futex 系 统 调用 实现 了 互 斥 量 。 








































































































glibc 的 互 斥 量 实现 ， 含 有 大 量 的 汇编 代码 ， 不 易 读 懂 ， 下 面 用 伪 代 码 来 描述 下 互 斥 量 的 加 锁 和 解锁 操作 : 





void lock (mutex* lock) 


int c:; 


if(c = cmpxchg (lock,0,1) != 0) 
// 如果 原始 值 是 


0， 则 表示 处 于 没 加 锁 的 状态 ， 将 


lock 改 成 


1， 直 接 返 回 


/ / 如果 原始 值 不 是 


0， 则 表示 互 斥 量 已 被 加 锁 ， 需 要 继续 执行 


do 
{ 
/* 此 处 有 以 下 可 能 性 : 


1) c==2 表示 已 被 加 锁 ， 并 且 有 其 他 正在 等 待 的 线程 
,应 立即 调用 
futex _wait2) 原子 地 检查 


lOCk 是 否 为 


如 果 是 ， 则 将 
lock 改 成 
2， 然 后 调用 


futex wait 
如 果 不 是 ， 则 表示 其 他 线程 释放 了 锁 ， 将 


lock 改 成 了 
0， 需 要 执行 


While 语句 争夺 锁 


Rp 


C == 11 cmpxchg (lock, 1, 2) != 0) 
/ /如 果 执 行 


futex_ wait 时 , 
lOCKk 已 经 被 改写 ， 不 等 于 


2， 则 当即 返回 


futex wait (lock, 2); 


} 
} while ( 


(c = cmpxchg (lock, 0, 2))! 


ll 
© 


/ /表示 有 线程 


Unlock,， 但 是 不 知道 解锁 后 是 


1 还 是 


2， 保 险 起 见 ， 写 成 


2 


Void unlock (mutex* lock) 
{ 
//atomic_dec 的 作用 是 减 


1 并 返回 原始 值 
if (atomic dec(lock) != 1) 
// 原始 值 是 


2， 有 线程 等 待 互 斥 量 ， 才 会 进入 


/ / 如果 原 始 值 是 


工 ， 则 表示 没有 线程 等 待 ， 没 必要 


futex wake 
lock = 0; 
futex wake (lock, 1); 
} 








上 再 





的 cmpxchg 和 atomic_dec 都 是 原子 操作 。 























cmpxchg (lock，a，b) : 表示 如 果 lock 的 值 等 于 a， 那 么 将 lock 改 为 5p， 并 将 原始 值 返回 ， 否 则 直接 将 原始 值 返回 。 

















“atomic_dec (lock) : 表示 将 lock 的 值 减 去 1， 并 且 返 


ka 





原始 值 。 











glibc 的 互 斥 量 中 维护 了 一 个 值 1ock， 该 值 有 以 下 三 种 情况 。 








:0: 表示 互 斥 量 并 未 上 锁 。 








“1: 表示 互 斥 量 已 经 上 锁 ， 但 是 并 没有 线程 正在 等 待 该 锁 。 






































:2: 表示 互 斥 量 已 经 上 锁 ， 并 且 有 线程 正在 等 待 该 锁 。 















































加 锁 时 ， 如 果 发 现 该 值 是 0， 那 么 直接 将 该 值 改 为 1， 无 须 执行 任何 系统 调用 ， 因 为 并 没有 线程 持 有 该 锁 ， 无 须 等 待 ; 





















































解锁 时 ， 如 果 发 现 该 值 是 1， 直 接 将 该 值 改 成 0， 无 须 执 行 任何 系统 调用 ， 因 为 并 没有 线程 正在 等 待 该 锁 ， 无 须 唤醒 。 






































当然 ， 在 这 两 种 情况 下 ， 比 较 和 修改 操作 (Compare And Swap) 必须 是 原子 操作 ， 和 否则 会 出 现 问题 。 如 果 无 竞争 ， 可 以 看 出 ， 互 斥 量 的 加 锁 
和 解锁 非常 轻 量 级 。 












































个 简单 的 实验 也 可 以 证 明 ， 无 竞争 条 件 下 ， 加 锁 解 锁 的 操作 是 很 轻 量 级 的 。 下 面 用 一 个 循环 执行 加 锁 和 解锁 操作 1000 万 次 ， 统 计 下 加 锁 
解锁 一 次 消耗 的 平均 时 间 ， 即 : 
































Clock gettime (CLOCK MONOTONIC, &start); 

for (int i = 0; i < TIMES; ++i) { 
pthread mutex lock(&lock); 
pthread mutex unlock (&lock); 


} 
clock gettime (CLOCK MONOTONIC, &end); 





在 笔者 用 的 2.13GHz i3 处 理 器 的 Ubuntu 上 ， 加 锁 解 锁 一 次 ， 平 均 消耗 24 纳 秒 左 右 ， 证 明了 在 无 竞争 的 条 件 下 ， 互 斥 量 的 加 锁 和 解锁 操作 的 确 
是 十 分 轻 量 级 的 。 




















接 下 来 考虑 存在 竞争 的 情况 ， 这 时 候 ， 就 需要 内 核 来 参与 了 。 




















内 核 提 供 了 futex_wait 和 futex_wake 两 个 操作 (futex 系 统 调用 支持 的 两 个 命令 ): 








int futex wait(int *uaddr, int val); 


int futex wake (int *uaddr，int n); 






































futex_wait 是 用 来 协助 加 锁 操 作 的 。 线 程 调用 pthread_mutex_ lock， 如 果 发 现 锁 的 值 不 是 0， 就 会 调用 futex_wait， 告 知 内 核 ， 线 程 须 要 等 待 在 
uaddr 对 应 的 锁 上 ， 请 将 线程 挂 起 。 内 核 会 建立 与 uaddr 地 址 对 应 的 等 待 队 列 。 






























































为 什么 需要 内 核 维护 等 待 队列 ? 因为 一 旦 互 斥 量 的 持 有 者 线程 释放 了 互 斥 量 ， 就 需要 及 时 通知 那些 等 待 在 该 互 斥 量 上 的 线程 。 如 果 没 有 等 待 
队列 ， 内 核 将 无 法 通知 到 那些 正 陷入 阻塞 的 线程 。 






































如 果 整 个 系统 有 很 多 这 种 互 斥 量 ， 是 不 是 需要 为 每 个 uaddr 地 址 建立 一 个 等 待 队列 昵 ? 事实 上 不 需要 。 理 论 上 讲 ，futex 只 需要 在 内 核 之 中 维 
护 一 个 队列 就 够 了 ， 当 线程 释放 互 斥 量 时 ， 可 能 会 调用 futex_ wake， 此 时 会 将 uaddr 传 进来 ， 内 核 会 去 遍历 该 队列 ， 查 找 等 竺 在 该 uaddr 地 址 上 的 线 
程 ， 并 将 相应 的 线程 唤醒 。 
























































但 是 只 有 一 个 队列 的 话 查 找 效 率 有 点 低 ， 作 为 优化 ， 内 核实 现 了 多 个 队列 。 插 入 等 待 队列 时 ， 会 先 计算 hash 值 ， 然 后 根据 hash 插 入 到 对 应 的 
链表 之 中 ， 如 图 7-16 所 示 。 




































































值得 一 提 的 是 ，fntex_wait 操 作 需 要 的 val 入 参 ， 乍 看 之 下 好 像 没 什么 用 处 。 事 实 上 并 非 如 此 。 从 用 户 程序 判断 锁 的 值 ， 到 调用 fntex_wait 操 作 
是 有 时 间 窗 口 的 ， 在 这 个 时 间 窗 口 之 内 ， 有 可 能 发 生 线程 解锁 的 操作 ， 从 而 可 能 无 须 等 待 。 因 此 futex_wait 操 作 会 检查 uaddr 对 应 的 锁 的 值 是 否 和 所 
于 val 的 值 ， 只 有 在 等 于 val 的 情况 下 ， 内 核 才 会 让 线程 等 待 在 对 应 的 队列 上 ， 否 则 会 立刻 返回 ， 让 用 户 程序 再 次 申请 锁 。 


线程 Al 
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进程 描述 符 B 进程 描述 符 A2 










进程 描述 符 A1 
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内 核 层 


图 7-16 ”futex 机 制 中 内 核 的 等 待 队 列 

















futex_wake 操 作 是 用 来 实现 解锁 操作 的 。glibc 就 是 使 用 该 操作 来 实现 互 斥 量 的 解锁 函数 pthread_mutex_unlock 的 。 当 线程 执行 完 临 界 区 代码 ， 
解锁 时 ， 内 核 需要 通知 那些 正在 等 待 该 锁 的 线程 。 这 时 候 就 需要 发 挥 fntex_wake 操 作 的 作用 了 。futex_ wake 的 第 二 个 参数 n， 对 于 互 斥 量 而 言 ， 该 
值 总 是 1， 表 示 唤 醒 1 个 线程 。 当 然 ， 也 可 以 唤醒 所 有 正在 等 待 该 锁 的 线程 ， 但 是 这 样 做 并 无 好 处 ， 因 为 被 唤醒 的 多 个 线程 会 再 次 竞争 ， 却 只 能 有 
一 个 线程 抢 到 锁 ， 这 时 其 他 线程 不 得 不 再 次 睡 去 ， 徒 增 了 很 多 开销 。 


























































































































使 用 strace 跟 踪 系 统 调用 的 时 候 ， 看 不 到 futex_wait 和 futex_wake 两 个 系统 调用 ， 看 到 的 是 futex 系 统 调用 ， 如 下 。 

















#include <linux/futex.h> 

#include <sys/time.h> 

int futex(int *uaddr, int op, int val, 

const struct timespec *timeout,int *uaddr2, int val3); 


















































该 系统 调用 是 一 个 综合 的 系统 调用 ， 根 据 第 二 个 参数 op 来 决定 具体 的 行为 。 当 op 为 FUTEX_WAIT 时 ， 对 应 的 是 前 面 讨论 的 futex_wait 操 作 ， 
当 op 为 FUTEX_WAKE 时 ， 对 应 的 是 前 面 讨论 的 futex_wake 操 作 。 















































细心 的 话 ， 可 以 发 现 ， 互 斥 量 加 锁 和 解锁 时 ， 调 用 futex 的 op 参数 并 非 FUTEX_ WAIT 和 FUTEX WAKE， 而 是 FUTEX WAIT _ PRIVATE 和 
FUTEX_WAKE PRIVATE， 这 是 为 了 改进 futex 的 性 能 而 进行 的 优化 。 因 为 fatex 也 可 以 用 在 不 同 的 进程 之 间 ， 加 上 后 缀 _ PRIVATE 是 为 了 明确 告知 
内 核 ， 互 斥 的 行为 是 用 在 线程 之 间 的 。 





















































从 上 面 的 角度 分 析 ， 当 存在 竞争 时 ， 如 果 线 程 申 请 不 到 互 斥 量 ， 就 会 让 出 CPU， 系 统 会 发 生 上 下 文 切换 。 在 线程 个 数 众多 ， 临 界 区 竞争 异常 
激烈 的 情况 下 ， 上 下 文 切换 会 是 一 笔 不 小 的 开销 。 



























































如 果 临 界 区 非常 小 ， 线 程 之 间 对 临界 区 的 竞争 并 不 激烈 ， 只 会 偶尔 发 生 ， 这 种 情况 下 ， 忙 -等 待 的 策略 要 优 于 互 斥 量 的 “让 出 CPU， 陷 入 阻 
塞 ， 等 待 唤醒 ?的 策略 。 采 用 忙 -等 待 策略 的 锁 为 自 旋 锁 。 


















































关于 futex 的 原理 ，Ulrich Drepper 《Futexes Are Tricky》 (11 一文 就 是 非常 好 的 参考 文献 。 





[1] Ulrich Drepper 的 《Futexes Are Tricky》， 详 见 http://www.akkadia.org/drepper/futex.pdf。 





7.7.$ 互 斥 锁 的 公平 性 


互 斥 锁 是 公平 的 吗 ? 











首先 要 定义 什么 是 公平 〈fairness) 。 对 于 锁 而 言 ， 如 果 A 在 B 之 前 调用 lock〈) 方法 ， 那 么 A 应 该 
先 于 B 获 得 锁 ， 进 入 临界 区 。 多 处 理 器 条 件 下 ， 很 难 确 定 是 哪个 线程 率先 调用 的 lock〈) 方法 。 纵 然 能 
判定 是 哪个 线程 率先 调用 的 lock() 方法 ， 要 实现 指令 级 的 公平 也 是 很 难 的 。 常 见 的 判断 锁 公 平 性 的 方 
法 是 ， 将 锁 的 实现 代码 分 成 如 下 两 个 部 分 : 























一 








门廊 区 


彼 


二 待 区 





门廊 区 必须 在 有 限 的 操作 内 完成 ， 等 待 区 则 可 能 有 无 穷 的 步骤 ， 它 们 会 陷入 未 知 结束 时 间 的 等 待 








如 果 锁 能 满足 以 下 条 件 ， 就 称 锁 是 先 来 先 服 务 〈FCFS) 的: 











如 果 线 程 A 门 廊 区 的 结束 在 线程 B 门 廊 区 的 开始 之 前 ， 那 么 线程 A 一 定 不 会 被 线程 B 赶 超 。 








互 斥 量 也 有 门 辜 区 和 等 竺 区， 就 像 7.7.4 节 分 析 的 ， 如 果 没 有 竞争 ， 线 程 执行 几 个 指令 就 加 锁 成 
功 ， 顺 利 返 回 了 。 在 这 种 情况 下 ， 互 斥 量 在 门廊 区 就 解决 了 所 有 的 需要 。 但 是 如 果 有 竞争 ， 互 斥 锁 在 
门廊 区 判断 出 存在 竞争 ， 线 程 取 不 到 锁 ， 就 不 得 不 执行 fatex_wait， 让 内 核 将 其 挂 起， 并 记录 在 等 待 队 
列 上 。 需 要 等 待 多 久 ? 不 知道 。 

















从 表面 上 看 ， 内 核 会 将 等 待 互 斥 量 的 线程 放 入 队列 ， 每 来 一 个 等 待 线程 ， 就 把 线程 记录 在 队列 的 
尾部 ， 当 互 斥 量 的 持 有 线程 解锁 时 ， 内 核 只 会 唤醒 一 个 线程 ， 而 唤醒 的 正 是 队列 中 等 待 该 互 斥 量 的 第 
一 个 等 待 者 。 队 列 的 先入 先 出 〈FIFO) ， 看 起 来 已 经 保证 了 互 斥 量 的 公平 性 。 但 是 ， 这 样 就 能 确保 公 
平 吗 ? 





























答案 是 否定 的 ， 互 斥 锁 并 没有 做 到 先 来 先 服务 。 








根据 7.7.4 节 的 伪 代 码 可 知 ， 当 互 斥 量 的 lock 的 值 是 2， 或 者 尝试 调用 CAS 操 作 将 lock 从 1 改 成 2 并 且 成 
功 时 ， 线 程 会 调用 futex_wait 鸣 入 阻塞 。 值 得 一 提 的 是 ，CAS 操 作 在 尝试 将 1 改 成 2 时 ， 也 可 能 存在 竞 
争 ， 比 如 其 他 线程 有 解锁 操作 ，lock 值 已 经 被 改 成 了 0， 而 这 时 候 恰 好 存在 另外 一 个 线程 刚刚 调用 加 锁 
操作 ， 这 时 就 会 发 生 门 廊 区 的 争夺 ， 对 于 这 种 情况 不 做 详细 分 析 。 假 设 加 锁 调用 了 futex_wait， 内 核 将 
线程 挂 起 在 等 竺 队列 上 ， 从 那 时 起 ， 线 程 就 进入 了 漫长 的 等 待 区 。 


























如 果 互 斥 量 的 持 有 线程 解锁 ， 会 首先 将 互 斥 量 的 lock 值 设置 成 0， 然 后 唤醒 内 核 等 待 队 列 中 等 待 在 
该 地 址 上 的 第 一 个 线程 。 看 起 来 比较 公平 ， 但 是 问题 就 出 在 此 处 ， 被 唤醒 的 线程 并 不 是 自动 就 持 有 了 
互 斥 锁 ， 反 而 须要 执行 while 〈() 中 包 庄 的 cmpxchg 操 作 ， 再 次 竞争 互 斥 量 。 如 果 竞 争 失败 ， 则 被 另外 一 
个 初来乍到 的 线程 将 0 改 成 了 1， 那 么 线程 刚刚 醒 来 就 不 得 不 再 次 执行 fhtex_wait， 再 次 沉睡 。 这 次 竞 
失败 的 代价 是 巨大 的 ， 因 为 futex_wait 操 作 会 将 线程 挂 载 到 等 待 队列 的 队 尾 。 






















































































由 上 面 的 分 析 可 以 得 出 如 下 结论 : 




















:线程 可 能 多 次 调用 futex_wait 进 入 等 待 区 ， 在 线程 被 futex_wait 唤 醒 后 ， 并 不 会 自动 拥有 互 斥 量 ， 而 
是 再 次 进入 门廊 区 ， 和 其 他 线程 争夺 锁 。 




















-在 已 经 有 很 多 线程 处 于 内 核 等 等 队列 的 情况 下 ， 新 来 的 加 锁 请 求 可 能 会 后 发 先 至 ， 率 先 获 得 锁 。 
































-futex_wait 唤 醒 的 线程 如 果 没 有 兖 争 到 锁 ， 那 么 会 再 次 调用 futex_wait 函 数 ， 陶 入 睡眠 ， 不 过 内 核 会 
将 其 放 入 等 待 队列 的 队 尾 ， 这 种 行为 加 剧 了 不 公平 性 。 

















所 以 ， 综 合 上 面 的 讨论 ， 互 斥 量 不 是 一 个 公平 的 锁 ， 没 有 做 到 先 来 先 服 务 。 关 于 futex 的 早期 论文 
《Fuss，Futexes and Furwocks: Fast Userlevel Locking in Linux》， 己 经 指出 了 这 个 问题 。futex_up fair 系 


统 调用 尝试 解决 这 个 不 公平 的 问题 ， 但 是 最 终 没 有 进入 内 核 主线 。 























为 什么 开发 者 并 不 在 意 这 种 不 公平 性 ?因为 要 实现 这 种 公平 性 会 牺牲 性 能 ， 而 这 种 牺牲 并 无 必 
要 。 绝 大 多 数 情 况 下 ， 由 于 调度 的 原因 ， 用 户 根 本 无 法 判断 哪个 线程 会 优先 调用 加 锁 操 作 ， 那 么 内 核 
或 glibc 维 持 这 种 先 来 先 服务 (FCFS) 就 变 得 毫 无 意义 。 如 果 可 以 在 不 牺牲 性 能 的 情况 下 做 到 公平 ， 自 
然 最 好 ， 但 是 实际 情况 并 非 如 此 。 实 现 这 种 公平 ， 对 性 能 的 伤害 很 大 。 就 像 Ulrich Drepple 在 Thread 
starvation with mutex 的 回复 中 所 说 的 : 









































Is there a reason why NPTL does not use this "fair" method? 
It's slow and unnecessary. 





综 上 所 述 ， 结 论 如 下 : 内 核 维护 等 待 队列 ， 互 斥 量 实现 了 大 体 上 的 公平 ， 由 于 等 待 线程 被 唤醒 
后 ， 并 不 自动 持 有 互 斥 量 ， 需 要 和 刚 进 入 门廊 区 的 线程 竞争 ， 所 以 互 斥 量 并 没有 做 到 先 来 先 服务 。 
































7.7.6 互 斥 锁 的 类 型 


前 面 讨论 的 都 是 默认 类 型 的 互 斥 锁 ， 除 默认 类 型 外 ， 互 斥 锁 还 有 几 个 变种 ， 它 们 的 行为 模式 和 默 
认 互 斥 锁 有 一 定 的 差异 。 














互 斥 量 有 以 下 4 种 类 型 : 





.PTHREAD MUTEX TIMED NP 


‘PTHREAD MUTEX RECURSIVE 


‘PTHREAD MUTEX ERRORCHECK 





.PTHREAD MUTEX ADAPTIVE NP 














glibc 提 供 了 接口 来 查询 和 设置 互 斥 锁 的 类 型 : 


#include <pthread.h> 
int pthread mutexattr gettype (Const pthread mutexattr t *restrict attr,int *restrict type); 
int pthread mutexattr settype (pthread mutexattr t *attr,int type); 


可 以 仿照 如 下 代码 来 设置 互 斥 量 的 类 型 








/* 忽 略 了 出 错 判断 ， 真 实 代码 中 需要 判断 


error*/ 

pthread mutex mtx; 

pthread mutexattr t mtxAttr; 

pthread mutexattr init (&mtxAttr); 

pthread mutexattr settype (&mtxAttr, PTHREAD MUTEX ADAPTIVE NP); 
pthread mutex init (gmtx, &mtxAttr); 














其 中 manual 给 出 了 4 种 类 型 ， 但 并 非 前 面 提 到 的 这 4 种 类 型 ， 略 有 差异 ， 差 异 在 于 : manual 中 存在 
PTHREAD MUTEX _ DEFAULT 类 型 ， 而 少 了 一 个 PTHREAD MUTEX _ ADAPTIVE NP 类 型 。manual 中 给 
出 的 是 标准 unix 98 定 义 的 4 种 类 型 。 


对 于 NPTL 的 实现 ， 有 具体 如 下 : 


THREAD MUTEX NORMAL 
THREAD MUTEX DEFAULT 


THREAD MUTEX TIMED NP, 
THREAD MUTEX NORMAL: 


ym 








[el 
mm 








所 以 ，glibc 的 实现 比 标准 的 Unix 98 多 了 一 个 PTHREAD MUTEX ADAPTIVE_NP 类 型 ， 下 面 来 分 别 


介绍 这 几 个 互 斥 量 的 特点 。 








.PTHREAD MUTEX NORMAL: 最 普通 的 一 种 互 斥 锁 。 前 文 讨论 的 就 是 这 种 类 型 的 锁 。 它 不 具备 
死 锁 检测 功能 ， 如 线程 对 自己 锁定 的 互 斥 量 再 次 加 锁 ， 则 会 发 生死 锁 。 














.PTHREAD_ MUTEX RECURSIVE NP: 支持 递归 的 一 种 互 斥 锁 ， 该 互 斥 量 的 内 部 维护 有 互 斥 锁 的 
所 有 者 和 一 个 锁 计数 器 。 当 线程 第 一 次 取 到 互 斥 锁 时 ， 会 将 锁 计数 器 置 1， 后 续 同一 个 线程 再 次 执行 加 
锁 操 作 时 ， 会 递增 该 锁 计 数 器 的 值 。 解 锁 则 递减 该 锁 计 数 器 的 值 ， 直 到 降 至 0， 才 会 真正 释放 该 互 斥 
量 ， 此 时 其 他 线程 才能 获取 到 该 互 斥 量 。 解 锁 时 ， 如 果 互 斥 量 的 所 有 者 不 是 调用 解锁 的 线程 ， 则 会 返 
回 EPERM。 






































:PTHREAD _MUTEX ERRORCHECK NP: 支持 死 锁 检测 的 互 斥 锁 。 互 斥 量 的 内 部 会 记录 互 斥 锁 的 
当前 所 有 者 的 线程 D“〔〈 调 度 域 的 线程 ID) 。 如 果 互 斥 量 的 持 有 线程 再 次 调用 加 锁 操 作 ， 则 会 返回 
EDEADIK。 解 锁 时 ， 如 果 发 现 调用 解锁 操作 的 线程 并 不 是 互 斥 锁 的 持 有 者 ， 则 会 返回 EPERM。 























终于 轮 到 PTHREAD MUTEX _ ADAPTIVE NP 这 种 类 型 了 。 这 种 类 型 堪 称 互 斥 锁 中 的 战斗 机 ， 特 点 
就 是 一 个 字 一 一 快 ，libc 的 文档 里 面 直接 将 其 称 为 fast mutex。 那 么 它 和 普通 的 互 斥 量 相 比 有 何 差异 ， 它 
是 如 何 快速 实现 的 呢 ? 


























所 有 锁 的 实现 都 会 面临 一 个 相同 的 问题 ， 加 锁 时 竞争 失败 了 该 怎么 办 ? 普通 互 斥 量 的 做 法 是 立刻 
调用 futex_wait， 陷 入 阻塞 ， 让 出 CPU， 安 静 地 等 待 内 核 将 其 唤醒 。 在 临界 区 非常 小 且 很 少 发 生 竞争 的 
情况 下 ， 这 种 策略 并 不 算 好 ， 因 为 如 果 该 线程 肯 自 旋 ， 很 可 能 只 需要 极 短 的 时 间 ， 它 就 能 等 到 锁 的 持 
有 线程 解锁 ， 继 续 执 行 。 而 调用 fatex_wait， 执 行 系统 调用 和 上 下 文 切 换 的 开销 可 能 远大 于 自 旋 。 















































出 于 这 种 考虑 ，8glibc 引 入 了 线程 自 旋 锁 。 自 旋 锁 采用 了 和 互 斥 量 完 全 不 同 的 策略 ， 自 旋 锁 加 锁 失 
败 ， 并 不 会 让 出 CPU， 而 是 不 停 地 尝试 加 锁 ， 直 到 成 功 为 止 。 这 种 机 制 在 临界 区 非常 小 且 对 临界 区 的 
争夺 并 不 激烈 的 场景 下 ， 效 果 非 常 好 ， 如 下 。 








#include <pthread.h> 

int pthread spin destroy(pthread spinlock t *lock); 

int pthread spin init(pthread spinlock t *lock, int pshared); 
int pthread spin lock(pthread spinlock t *lock); 

int pthread spin trylock(pthread spinlock t *lock); 

int pthread spin unlock(pthread spinlock t *lock); 





自 旋 锁 的 效果 好 ， 但 是 副作用 也 大 ， 如 果 使 用 不 当 ， 自 旋 锁 的 持 有 者 迟 迟 无 法 释放 锁 ， 那 么 ， 自 
旋 接 近 于 死 循 环 ， 会 消耗 大 量 的 CPU 资源 ， 造 成 CPU 使 用 率 碳 高 。 因 此 ， 使 用 自 旋 锁 时 ， 一 定 要 确保 临 
界 区 尽 可 能 地 小 ， 不 要 有 系统 调用 ， 不 要 调用 sleep。 使 用 strcpymemcpy 等 函数 也 需要 谨慎 判断 操作 内 
存 的 大 小 ， 以 及 是 否 会 引起 缺 页 中 断 。 



































自 旋 锁 副作用 大 ， 而 互 斥 量 在 某 些 情况 下 效率 可 能 不 够 高 ， 有 没有 一 种 方法 能 够 结合 两 种 方法 的 
长 处 呢 ? 





x 








答案 是 肯定 的 。 这 就 是 PTHREAD MUTEX _ ADAPTIVE NP 类 型 的 互 斥 量 ， 也 被 称 为 自 适 应 锁 。 大 
多 数 操作 系统 (Solaris、Mac OS X、FreeBSD) 都 有 类 似 的 接口 ， 如 果 竞 争 锁 失 败 ， 首 先 与 自 旋 锁 
样 ， 持 续 尝试 获取 ， 但 过 了 一 定时 间 仍 然 不 能 申请 到 锁 ， 就 放弃 尝试 ， 让 出 CPU 并 等 待 。 

PTHREAD MUTEX _ ADAPTIVE NP 类 型 的 互 斥 量 ， 采 用 的 就 是 这 种 机 制 ， 如 下 : 


























if (LLL MUTEX TRYLOCK (mutex) != 0) 
{ 


int cnt = 0; 
int max cnt = MIN (MAX ADAPTIVE COUNT, 
mutex-> data. spins * 2 + 10); 
do 
{ 
if (cnt++ >= max cnt) 


/* 自 旋 也 没有 等 到 锁 ， 只 能 睡 去 


去 1 
LLL MUTEX LOCK (mutex); 
break; 


} 
#ifdef BUSY WAIT NOP 
BUSY WAIT NOP; 
#endif 
} 
while (LLL MUTEX TRYLOCK (mutex) != 0); 


mutex-> data. spins += (cnt - mutex-> data. spins) / 8; 
. 


到 底 等 待 多 长 时 间 才 合适 呢 ? 这 种 互 斥 量 定义 了 一 个 名 为 、spins 的 变量 ， 该 值 和 
MAX ADAPTIVE_COUNT 共 同 决 定 自 旋 多 和 久 。 该 类 型 之 所 以 叫 自 适应 (ADAPTIVE) ， 是 因为 带 有 反 
馈 机 制 ， 它 会 根据 实际 情况 ， 智 能 地 调整 _spins 的 值 。 

















mutex-> data. spins += (cnt - mutex-> data. spins) / 8; 











当然 自 旋 不 是 无 止境 的 向 上 增长 时 ，MAX ADAPTIVE COUNT 决定 了 上 限 ， 即 调用 
BUSY_WAIT_NOP 的 最 大 次 数 : 





# define MAX ADAPTIVE COUNT 100 





对 于 7.7.1 节 中 对 global_cnt 自 加 1000 万 次 的 程序 ， 如 果 把 for 循 环 体内 的 锁 换 成 自 适 应 互 斥 锁 ， 会 比 
普通 的 互 斥 量 更 快 吗 ? 答案 是 否定 的 ， 在 这 种 时 时 刻 刻 要 加 锁 和 解锁 的 激烈 竞争 下 ， 让 其 他 线程 睡 
去 ， 利 用 上 下 文 切换 的 时 间 间 隔 ， 让 一 个 线程 飞快 地 自如， 执行 时 间 反 而 是 最 短 的 。 























但 是 ， 真 实 场 景 下 临界 区 的 争夺 不 可 能 激烈 到 这 种 程度 ， 如 果 苋 争 真 的 激烈 到 这 种 程度 ， 那 首先 
需要 反省 的 是 设计 问题 。 在 临界 区 非常 小 ， 偶 尔 发 生 竞争 的 情况 下 ， 自 适应 互 斥 锁 的 性 能 要 优 于 普通 
的 互 斥 锁 。 




















7.7.7 “和 死 锁 和 活 锁 

















对 于 互 斥 量 而 言 ， 可 能 引起 的 最 大 问题 就 是 死 锁 〈dead lock) 了 。 最 简单 、 最 好 构造 的 死 锁 就 是 
图 7-17 所 示 的 这 种 场景 了 。 





图 7-17” 死 锁 的 产生 (简单 场景 ) 





线程 1 已 经 成 功 拿 到 了 互 斥 量 1， 正 在 申请 互 斥 量 2， 而 同时 在 另 一 个 CPU 上 ， 线 程 2 已 经 拿 到 了 互 
斥 量 2， 正 在 申请 互 斥 量 1。 彼 此 占有 对 方正 在 申请 的 互 斥 量 ， 结 局 就 是 谁 也 没 办 法 拿 到 想 要 的 互 斥 
量 ， 于 是 死 锁 就 发 生 了 。 














上 面 的 例子 比较 简单 ， 但 实际 工程 中 死 锁 可 能 会 发 生 在 复杂 的 函数 调用 之 中 。 可 以 想象 随 着 程序 
复杂 度 的 增加 ， 很 多 死 锁 并 不 像 上 面 的 例子 那样 一 目 了 然 ， 如 图 7-18 所 示 。 








资源 1 











图 7-18” 死 锁 的 产生 (复杂 场景 ) 


在 多 线程 程序 中 ， 如 果 存 在 多 个 互 斥 量 ， 一 定 要 小 心 防范 死 锁 的 形成 。 








存在 多 个 互 斥 量 的 情况 下 ， 避 免 死 锁 最 简单 的 方法 就 是 总 是 按照 一 定 的 先后 顺序 申请 这 些 互 斥 
量 。 还 是 以 刚才 的 例子 为 例 ， 如 果 每 个 线程 都 按照 先 申 请 互 斥 量 1， 再 申请 互 斥 量 2 的 顺序 执行 ， 死 锁 
就 不 会 发 生 。 有 些 互 斥 量 有 明显 的 层级 关系 ， 但 是 也 有 一 些 互 斥 量 原本 就 没有 特定 的 层级 关系 ， 不 过 
没有 关系 ， 可 以 人 为 干预 ， 让 所 有 的 线程 必须 遵循 同样 的 顺序 来 申请 互 斥 量 。 















































男 一 种 方法 是 尝试 一 下 ， 如 果 取 不 到 锁 就 返回 。Linux 提 供 了 如 下 接口 来 表达 这 种 思想 : 


int pthread mutex trylock(pthread mutex 七 *mutex); 
int pthread mutex timedlock (pthread mutex t?*restrict mutex, const struct timespec *restrict abs timeout); 








这 两 个 函数 反应 了 这 种 尝试 一 下 ， 不 行 就 算 了 的 思想 。 


对 于 pthread_mutex_trylock() 接口 ， 如 果 互 斥 量 已 然 被 锁定 ， 那 么 当即 返回 EBUSY 错 误 ， 而 不 像 
pthread mutex lock〈) 接口 一 样 陷入 阻塞 。 








对 于 pthread_mutex_timedlock() 接口 ， 提 供 了 一 个 时 间 参 数 abs_timeout， 如 果 申 请 互 斥 量 的 时 
候 ， 互 斥 量 已 被 锁定 ， 那 么 等 待 ， 如 果 到 了 abs_ timeout 指 定 的 时 间 ， 仍 然 没 有 申请 到 互 斥 量 ， 那 么 返回 
ETIMEOUT 错 误 。 











除 此 以 外 ， 这 两 个 接口 的 表现 与 pthread mutex lock 是 一 致 的 。 在 实际 的 应 用 中 ， 这 两 个 接口 使 用 
的 频率 远 低 于 pthread mutex lock 函 数 。 








trylock 不 行 就 回 退 的 思想 有 可 能 会 引发 活 锁 〈live lock) 。 生 活 中 也 经 常 遇 到 两 个 人 迎面 走 来 ， 双 
方 都 想 给 对 方 让 路 ， 但 是 让 的 方向 却 不 协调 ， 反 而 互相 墙 住 的 情况 (如 图 7-19 所 示 〉。 活 锁 现 象 与 这 
种 场景 有 点 类 似 。 





| 


i 


图 7-19 ”让 路 总 让 到 一 起 ， 变 成 堵 路 











考虑 下 面 两 个 线程 ， 线 程 1 首先 申请 锁 mutex_a 后 ， 之 后 尝试 申请 mutex_b， 失 败 以 后 ， 释 放 mutex_a 
进入 下 一 轮 循环 ， 同 时 线程 2 会 因为 尝试 申请 mutex_a 失 败 ， 而 释放 mutex_b， 如 果 两 个 线程 恰好 一 直 保 
持 这 种 节 委 ， 就 可 能 在 很 长 的 时 间 内 两 者 都 一 次 次 地 控 肩 而 过 。 当 然 这 毕竟 不 是 死 锁 ， 终 完 会 有 一 个 
线程 同时 持 有 两 把 锁 而 结束 这 种 情况 。 尽 管 如 此 ， 活 锁 的 确 会 降低 性 能 。 这 种 情况 的 示例 代码 如 下 : 

















/ /线程 


void funcl () 
{ 
int ‘done = 0}; 
while (!done) 
{ 
pthread mutex lock(&mutex a); 
if (pthread mutex trylock (&mutex b)) 
{ 


countertt+; 
pthread mutex unlock(&mutex b); 
pthread mutex unlock (&mutex a); 
done = 1; 

} 

else 

{ 


pthread mutex unlock(&mutex a); 


void func2 () 
{ 
int done = 0; 
while (!done) 
{ 
pthread mutex lock (&mutex b); 
if (pthread mutex trylock (&mutex a)) 
{ 
countertt+; 
pthread mutex unlock (&mutex a); 
pthread mutex unlock (&mutex b); 
done = 1; 
} 
else 
{ 


pthread mutex unlock (&mutex b); 





7.8 读 写 锁 

















很 多 时 候 ， 对 共享 变量 的 访问 有 以 下 特点 : 大 多 数 情况 下 线程 只 是 读 取 共 享 变量 

















* 享 变量 的 值 。 

















对 于 这 种 情况 ， 读 请 求 之 间 是 无 需 同 步 的 ， 它 们 之 间 的 并 发 访问 是 安全 的 。 然 而 写 请 求 必须 锁 住 读 请 求 和 : 





这 种 情况 在 实际 中 是 存在 的 ， 比 如 配置 项 。 大 多 数 时 间 内 ， 配 置 是 不 会 发 4 























止 读 请 求 并 发 ， 则 会 造成 性 能 的 损失 。 





出 于 这 种 考虑 ，POSIX 引 入 了 读 写 锁 。 











读 写 锁 比 较 简 单 ， 从 表 7-11 可 以 看 出 ， 








当前 锁 状 态 


























对 于 这 种 情况 ， 读 写 锁 做 了 优化 ， 允 许 大 家 一 起 读 。 


表 7-11 读 写 锁 的 行为 


疯 
O 
O 


的 值 ， 并 不 修改 ， 只 有 极 少数 情况 下 ， 线 程 才 会 真正 地 修改 





其 他 写 请 求 。 




















E 变 化 的 ， 偶 尔 会 4 














b 现 修改 配置 的 情况 。 如 果 使 用 互 斥 量 ， 完 全 阻 








写 锁 请 求 
OK 
阻塞 
阻塞 


7.8.1 读 写 锁 的 接口 


1. 创 建 和 销毁 读 写 锁 























NTPL 提 供 了 pthread rwlock t 类 型 来 表示 读 写 锁 。 和 互 斥 量 一 样 ， 它 也 提供 了 两 种 初始 化 的 方法 : 











#include <pthread.h> 
int pthread rwlock init(pthread rwlock t *rwlock, 
加 const pthread rwlockattr 七 *attr); 
int pthread rwlock destroy (pthread rwlock t *rwlock); 
pthread rwlock t rwlock=PTHREAD RWLOCK INITIALIZER; 




















被 写 锁 阻 塞 。 后 面 会 详细 讨论 读者 优先 和 写 者 优先 对 读 写 锁 的 影 














对 于 静态 变量 ， 可 以 采用 PTHREAD_RWLOCK INITIALIZER 赋 值 的 方式 初始 化 ， 对 于 动态 分 配 的 读 写 锁 ， 或 者 非 默 认 属 性 的 读 写 锁 ， 需 要 
jpthread rwlock init 函 数 进行 初始 化 。 如 果 第 二 个 属性 的 参数 为 NULL， 那 么 采用 默认 属性 。 






































t 

















读 写 锁 的 默认 属性 如 表 7-12 所 示 。 











表 7-12 读 写 锁 的 默认 属性 


进程 内 部 竞争 读 写 锁 
读者 优先 





























请 者 获得 读 锁 ， 而 不 是 


PT 
en 
用 


所 谓 读者 优先 的 策略 ， 是 指 当前 锁 的 状态 是 读 锁 ， 如 果 线 程 申请 读 锁 ， 此 时 纵然 有 写 锁 在 等 待 队列 上 ， 仍 然 允 许 















































下 


o 























对 于 调用 pthread rwlock init 初 始 化 的 读 写 锁 ， 在 不 需要 读 写 锁 的 时 候 ， 需 要 调用 pthread_ rwlock destroy 销 毁 ， 如 下 : 














#include <pthread.h> 
int pthread rwlock destroy (pthread rwlock t *rwlock); 





2. 读 写 锁 的 加 锁 和 解锁 














读 写 锁 又 称 共享 -独占 锁 ， 有 共享 ， 也 有 独占 。 























下 面 是 三 个 读 锁 上 锁 的 接 


加 























int pthread rwlock rdlock(pthread rwlock 七 *rwlock); 
int pthread rwlock tryrdlock (pthread rwlock 七 *rwlock); 
int pthread rwlock timedrdlock (pthread rwlock 七 *rwlock,const struct timespec *abstime); 








而 下 面 三 个 是 写 锁 上 锁 的 接 





[| 














int pthread rwlock wrlock(pthread rwlock 七 *rwlock); 
int pthread rwlock trywrlock (pthread rwlock 七 *rwlock); 
int pthread rwlock timedwrlock (pthread rwlock 七 *rwlock,const struct timespec *abstime); 
























































读 锁 用 于 共享 模式 。 如 果 当 前 读 写 锁 已 经 被 某 线程 以 读 模式 占有 了 ， 那 么 其 他 线程 调用 pthread_rwlock_rdlock 会 立刻 获得 读 锁 ;如果 当 前 读 
写 锁 已 经 被 某 线 程 以 写 模式 占有 了 ， 那 么 调用 pthread_rwlock rdlock 会 陷入 阻塞 。 
















































































写 锁 用 的 是 独占 模式 。 如 果 当 前 读 写 锁 被 某 线程 以 写 模式 占有 ， 则 不 允许 任何 读 锁 请 求 通过 ， 也 不 允许 任 何 写 锁 请 求 通过 ， 读 锁 请 求 和 写 



































锁 请 求 都 要 陷入 阻塞 ， 直 到 线程 释放 写 锁 。 





无 论 是 读 锁 还 是 写 锁 ， 锁 的 释放 都 是 一 个 接口 : 








int pthread rwlock unlock (pthread rwlock t *rwlock); 























I 











， 错 误 码 是 EBUSY。 





用 线程 不 会 阻塞 ， 而 会 立即 返 








无 论 是 读 锁 还 是 写 锁 ， 都 提供 了 trylock 的 功能 ， 当 不 能 获得 读 锁 或 写 锁 时 ，j 


ie 


























I 


， 错 误 











无 论 是 读 锁 还 是 写 锁 都 提供 了 限时 等 待 ， 如 果 不 能 获取 读 写 锁 ， 则 会 陷入 阻塞 ， 最 多 等 待 到 abstime， 如 果 仍 然 无 法 获得 锁 ， 则 返 











码 是 ETIMEOUT。 























从 表面 上 看 ， 读 写 锁 介绍 到 此 处 就 可 以 打 完 收工 了 ， 其 实 不 然 ， 读 写 锁 是 两 种 类 型 的 锁 ， 当 它们 都 存在 时 ， 它 们 之 间 的 竞争 关系 如 何 ? 如 
果 同 时 到 来 一 大 拨 读 锁 请 求 和 写 锁 请 求 ， 它 们 之 间 的 响应 又 有 什么 特点 ? 事实 上 ， 这 些 是 由 读 写 锁 的 策略 决定 的 。 







































































7.8.2” 读 写 锁 的 竞争 策略 























读 写 锁 的 属性 是 pthread_rwlockattr {类 型 ， 属 性 中 有 两 个 部 分 : lockkind 和 pshared。 本 节 只 讲 lockkind。 
































所 谓 lockkind， 表 示 读 写 锁 表 现 出 什么 样 的 行为 艺术 。 对 于 读 写 锁 ， 目 前 有 两 种 策略 ， 一 是 读者 优先 ， 一 是 写 者 优先 。 


glibc 引 入 了 如 下 接口 来 查询 和 改变 读 写 锁 的 类 型 : 








int Pthread rwlockattr getkind np (const Pthread rwlockattr t * attr, int * pref); 
int pthread . rwlockattr : setkind np(pthread rwlockattr 七 * attr, int * pref); 








其 中 ， 读 写 锁 类 型 的 可 能 值 有 如 下 几 种 : 

















enum 


PTHREAD_RNLOCK_PREFER_RERADER_NP， // 读 者 优先 


PTHREAD_RNLOCK_PREFER_NRITER_NP， // 很 晓 人 ， 但 是 也 是 读者 优先 


PTHREAD RWLOCK PREFER WRITER NONRECURSIVE_NP,，// 写 者 优先 


PTHREAD RWLOCK DEFAULT NP = PTHREAD RWLOCK PREFER READER NP 


























前 两 个 都 是 读者 优先 的 策略 ， 尤 其 要 注意 其 中 的 第 二 个 ， 名 字 取 得 很 “变态 ”， 名 为 PREFER_WRITE 却 干 着 “ 提 
三 个 是 写 者 优先 的 策略 。 从 pthread rwlock init 函 数 中 可 以 看 出 端倪 : 

















Fr 


羊 头 卖 狗肉 ”的 勾当 。 只 有 第 








中 | 
































rwlock-> data. flags 
= iattr->lockkind == PTHREAD RWLOCK PREFER WRITER NONRECURSIVE NP; 








可 以 看 到 ， 只 有 PTHREAD RWLOCK PREFER_ WRITER NONRECURSIVE NP 是 写 者 优先 ， 其 他 一 律 都 是 读者 优先 。 读 写 锁 的 默认 行为 是 
读者 优先 。 

















那么 ， 什 么 是 读者 优先 呢 ? 





如 果 当 前 锁 的 状态 是 读 锁 ， 并 存在 写 锁 请 求 被 阻塞 ， 那 么 在 写 锁 后 面 到 来 的 读 锁 请 求 该 如 何 处 理 就 成 了 问题 的 关键 。 
































如 果 在 写 锁 请 求 后 面 到 来 的 读 锁 请 求 不 被 写 锁 请 求 阻塞 ， 就 可 以 立即 响应 ， 写 锁 的 下 场 可 能 会 比较 悲惨 。 如 果 读 锁 请 求 前 赴 后 继 源 源 不 断 
地 到 来 ， 只 要 有 一 个 读 锁 没 完成 ， 写 锁 就 没 份 。 这 就 是 所 谓 的 读者 优先 。 
































从 图 7-20 可 以 看 出 ， 这 种 策略 是 不 公平 的 ， 极 端 情况 下 ， 写 请 求 很 可 能 被 饿 死 。 这 就 是 多 线程 中 的 饥饿 〈Starvation) 现象 ， 即 某 些 线程 总 
是 得 不 到 锁 资源 


线程 1 
线程 2 
线程 3 
线程 4 


图 7-20 ” 较 早 到 的 写 锁 请 求 被 饿 死 

















晚 于 写 锁 请 求 到 来 的 读 锁 请 求 不 排队 乱 加 塞 的 行为 引起 了 写 锁 申请 者 的 强烈 不 满 : 凭 啥 仅仅 因为 当前 是 读 锁 ， 比 我 晚 来 的 读 锁 申请 者 就 不 











用 排队 ， 直 接 响应 ?鉴于 此 ，glibc 又 实现 了 写 者 优先 的 策略 。 






























































所 谓 写 者 优先 是 指 ， 如 果 当 前 是 读 锁 ， 有 很 多 线程 在 共享 读 锁 ， 这 是 允许 的 ， 但 是 一 旦 线程 申请 写 锁 ， 在 写 锁 请 求 后 面 到 来 的 读 锁 请 求 就 





先 于 写 请 求 拿 到 锁 。 





CC 


不 外 


会 统统 被 阻塞 








8glibc 是 如 何 做 到 这 点 的 ? 它 引 入 了 表 7-13 中 的 变量 。 


表 7-13 ” 读 写 锁 实现 中 的 变量 及 含义 








变 量 说 明 
_ lock 管理 读 写 锁 全 局 竞争 的 锁 ， 无 论 是 读 锁 写 锁 还 是 解锁 ， 都 会 执行 互 斥 
__writer 写 锁 持 有 者 的 线程 ID ， 如 果 为 0 则 表示 当前 无 线程 持 有 写 锁 
__ nr readers 读 锁 持 有 线程 的 个 数 
_mnr readers queued 读 锁 的 排队 等 待 线程 的 个 数 
__ nr writers_queued 写 锁 的 排队 等 待 线程 的 个 数 
无 论 是 申请 读 锁 还 是 申请 写 锁 ， 还 是 解锁 ， 都 至 少 会 做 一 次 全 局 互 斥 锁 〈 对 应 _lock) 的 加 锁 和 解锁 ， 若 不 考虑 阻塞 ， 单 单 考 虑 操作 本 身 的 

























































































开销 ， 读 写 锁 的 加 解锁 开销 是 互 斥 锁 的 两 倍 。 当 然 ， 函 数 结束 前 或 进入 阻塞 之 前 ， 会 将 全 局 的 互 斥 锁 释 放 。 下 面 的 讨论 先 暂 时 忽略 该 全 局 的 互 














斥 锁 。 





对 于 读 锁 请 求 而 言 ， 如 果 : 





:无 线程 持 有 写 锁 ， 即 writer==0。 




















:采用 的 是 读者 优先 策略 或 没有 写 锁 等 待 者 〈_mr_writers_queued=0) 。 




















满足 这 两 个 条 件 时 ， 读 锁 请 求 都 可 以 立刻 获得 读 锁 ， 返 回 之 前 执行 _nr_readers++， 表 示 多 了 一 个 线程 占有 读 锁 。 


Lk 




















不 满足 的 话 ， 则 执行 _mr_readers_queued++， 表 示 增 加 一 个 读 锁 等 待 者 ， 然 后 调用 futex， 陷 入 阻塞 。 醒 来 之 后 ， 会 先 执行 


_mr readers_ queued--， 然 后 再 次 判断 是 否 同时 满足 条 件 1 和 2。 





























对 于 写 请 求 而 言 ， 如 果 : 





:无 线程 持 有 写 锁 ， 即 writer==0。 











:没有 线程 持 有 读 锁 ， 即 “nr readers==0。 


























只 要 满足 上 述 条 件 ， 就 会 立刻 拿 到 写 锁 ， 将 _ writer 置 为 线程 的 ID〈 调 度 域 ) 。 












































如 果 不 满足 ， 那 么 执行 _mr_ writers_queued++， 表 示 增 加 一 个 写 锁 等 待 者 线程 ， 然 后 执行 fntex 陷 入 等 待 。 醒 来 后 ， 限 制 性 


_nr_writers_queued--， 然 后 重新 判断 条 件 1 和 2。 

















对 于 解锁 而 言 ， 如 果 当 前 锁 是 写 锁 ， 则 执行 如 下 操作 : 











1) 执行 _writer=0， 表 示 释 放 写 锁 。 








2) 根据 _nr_writers_queued 判 断 有 没有 写 锁 等 竺 者， 如果 有 ， 则 唤醒 一 个 写 锁 等 待 者 。 

















如 果 没 有 写 锁 等 待 者 ， 则 判断 有 没有 读 锁 等 待 者 ， 如 果 有 ， 则 将 所 有 的 读 锁 等 待 者 一 起 唤醒 。 




















如 果 当 前 锁 是 读 锁 ， 则 执行 如 下 操作 : 











1) 执行 _mr readers--， 表 示 读 锁 占 有 者 少 了 一 个 。 











y 





2) 


“根据 _ nr_writers_queuedy 





:如 果 没 有 写 锁 科 








判断 _nr_readers 是 否 等 于 0， 是 的 话 则 表示 























己 是 最 后 








-万 














车 待 者 ， 














从 上 面 











的 流程 可 以 看 


HH 
0 








请 求 线程 。 因 此 如 果 当 前 读 写 






































死 。 





9 


判断 是 否 存 在 写 


写 者 优先 也 存在 


锁 等 待 




















锁 状 态 是 写 锁 ， 








了 


私 的 倾向 ， 
时 到 来 很 多 写 请 求 和 读 请 求 ， 那 它 ; 














者 ， 若 有 ， 








个 读 锁 占有 者 ， 


则 


判断 是 否 存在 读 锁 等 待 者 ， 若 有 ， 则 唤醒 所 有 的 


因为 写 锁 解锁 






































需要 唤醒 写 锁 等 待 者 或 读 锁 等 待 者 : 






































唤醒 一 个 写 锁 等 待 线程 。 
区 锁 等 待 者 。 

的 时 候 ， 首 先 会 去 查找 有 没有 阻塞 的 写 锁 请 求 ， 如 果 有 ， 先 唤醒 写 锁 

和 总 是 优先 处 理 写 请 求 。 如 果 写 锁 请 求 源源 不 断 地 到 来 ， 那 




















厅 可 以 看 




















到 ， 





也 源源 不 断 














它 一 样 会 将 读 锁 请 求 饭 
通过 上 面 的 分 

在 读者 优先 的 策略 下 ， 

前 锁 的 状态 是 写 锁 ， 而 写 锁 
下 面 是 


个 读 写 锁 的 程序 ，| 




















来 验 i 


如 果 存 在 大 量 的 读 写 请 求 ， 
几乎 总 是 读 锁 请 求 先 得 到 响应 ， 


也 到 来 ， 这 时 候 ， 读 请 求 就 会 被 饿 死 。 


争 非常 激 





F 下 ， 








写 锁 被 四 


E 这 种 惯性 : 








日 塞 ， 因 








读 写 锁 存 在 很 大 的 惯性 ， 
8 现 写 请 求 被 铁 死 的 情况 。 解 芭 














如 果 当 前 锁 的 状态 是 读 锁 状 态 ， 


的 方法 是 设 定 成 写 者 优先 。 














I 








#include <stdi 
#include <stdl 
#include <pthr 


oh> 
1 
ead.h> 


#define N THREAD 100 


static int sha 


re cnt = 0; 


static pthread rwlock t rwlock ; 
void *reader (void *param) 


{ 
int i = 
while(1) 
{ 


(i 


pthread rwlock rdlock (&rwlock) 
fprintf (stderr, "reader-%d: the 


nt) param; 


pthread rwlock unlock (&rwlock) ， 


} 
return NUL 


void *writer (Vv 


{ 


int i 
while(1) 
{ 


pthread rwlock wrlock (&rwlock) 


share 


fprintf (stderr, "writer-%d: the 


(int) 


LD; 
oid *param) 


param; 


从 肌 丰 下 员 区 


7 


pthread rwlock unlock (&rwlock) ， 
人 


} 


Sleep (1); 


return NULL; 


main() 


pthread t tid[N THREAD] ; 


pthread rwlockattr t 


rwlock attr ; 


pthread . rwlockattr init (grwlock . attr); 


#ifdef WRITE F 


IRST 


bb 
share_cnt 


share_cnt 


Sd\n",i,share cnt); 


$0oN\n" i share CD 


pthread . rwlockattr setkind np (&rwlock attr,PTHREAD RWLOCK PREFER WRITER NONRECURSIVE NP); 


#endif 


pthread rwlock init(g&rwlock,&rwlock attr); 


int i = 
int wet 


= 0; 


07 


pthread rwlock rdlock(&rwlock); 


J, 


] 


for(i = Des | THREAD i++) 
{ 
if(i%2 == 0) 
: 
ret = pthread create{(&tid[i 
} 
Sle 
{ 
ret = pthread create (&tid[i 
} 
if(ret != 0) 


{ 


NULL, reader, (void*)i); 


:NULL, writer, (void*)i); 


fprintf (stderr, "create thread %d failed \n",i); 
break; 


} 
上 


pthread rwlock unlock(&rwlock); 
while(i-- >0) 


€ 


pthread join (tid[i],NULL); 


} 


pthread rwlockattr destroy(&rwlock attr); 
pthread rwlock destroy(&rwlock); 


return ret 


吕 





创建 100 个 线程 〈50 个 读 线程 和 5$0 个 写 线程 ) ， 读 线程 只 














读 写 竞争 非常 激烈 的 情况 。 创 建 线 程 之 前 ， 主 线程 会 持 有 读 写 锁 ， 
竞争 读 写 锁 。 





如 果 采 月 





昌 读 





者 优先 的 策 


后 ，share_cnt 仍 然 是 0。 











如 果 我 们 采 
求 ， 而 写 锁 释放 


写 者 优先 
的 时 候 ， 

















略 ， 





则 会 看 到 











于 读 线程 源源 不 断 地 


读 取 share_cnt 














直到 所 有 线程 创建 完毕 ， 


























的 策略 ， 情 况 就 


总 是 先 唤醒 写 锁 ， 


一 
完全 





表现 


人 相反 了 ， 











请 读 锁 ， 





从 第 

















出 来 很 强大 的 惯性 





的 值 ， 而 写 线程 会 


写 锁 被 活活 饿 死 ， 














将 share_cnt 的 值 
主线 程 解锁 ， 


由 于 是 while 循 环 ， 所 以 
闻 放 水 ， 放 任 100 个 线程 激 














Br 
肯 























烈 


DY 


了 然后 








写 线程 根本 捞 不 到 机 会 执行 。 运 行 N 秒 之 











个 写 锁 请 求 拿 到 锁 之 后 ， 


o 





读 锁 请 求 就 再 也 拿 不 到 锁 了 ， 











原 

















那么 能 否 实现 一 款 公平 的 读 写 锁 呢 ? 答案 是 肯定 的 。Locklessinc.com 中 有 一 篇 题 为 《Sleeping Read-Write Locks》 1 ， 在 分 析 glibc 实 现 的 基 
础 上 ， 给 出 了 一 种 公平 的 实现 读 写 锁 的 方法 ， 测 试 下 来 效率 很 不 错 。 对 锁 的 实现 感 兴趣 的 话 ， 可 以 阅读 该 文章 。 














[1] 《Sleeping Reader-Writer Lock》 ， 请 参见 http://locklessinc.conyarticles/sleeping rwlocks/。 


7.8.3” 读 写 锁 总 结 























从 宏观 意义 上 看 ， 读 写 锁 要 比 互 斥 量 并 发 性 好 ， 因 为 读 写 锁 在 更 多 的 时 间 区 域内 允许 并 发 。 





如 果 认 为 读 写 锁 是 完美 的 ， 以 至 于 认为 互 斥 锁 没 有 存在 的 必要 ， 那 就 是 too young，too 
simple，sometimes naive 了 。Bryan Cantrill 和 Je 你 Bonwick 在 《Real-world Concurrency》 中 提出 的 并 发 编 
程 的 建议 里 提 到 了 要 警惕 读 写 锁 (Be wary of readers-writer locks) 。 读 写 锁 存 在 如 下 的 短处 。 




















性 能 : 如 果 临 界 区 比较 大 ， 读 写 锁 高 并 发 的 优势 就 会 显现 出 来 ， 但 是 如 果 临 界 区 非常 小 ， 读 写 锁 
的 性 能 短 板 就 会 暴露 出 来 。 由 于 读 写 锁 无 论 是 加 锁 还 是 解锁 ， 首 先 都 会 执行 互 斥 操作 ， 加 上 读 写 锁 还 
需要 维护 当前 读者 线程 的 个 数 、 写 锁 等 待 线程 的 个 数 、 读 锁 等 待 线程 的 个 数 ， 因 此 这 就 决定 了 读 写 锁 
的 开销 不 会 小 于 互 斥 量 。 
































' 饭 死 : 互 斥 量 虽 然 不 是 绝对 意义 上 的 公正 ， 但 是 线程 不 会 饿 死 。 但 是 如 上 一 小 节 的 讨论 ， 读 者 优 
先 的 策略 下 ， 写 线程 可 能 会 饿 死 。 写 者 优先 的 情况 下 ， 读 线程 可 能 会 饿 死 。 








` 死 锁 : 读 锁 是 可 重 入 的 ， 这 就 可 能 会 引发 死 锁 。 考 虑 如 下 场景 ， 读 写 锁 采 用 写 者 优先 的 策略 ，A 
线程 己 经 持 有 读 锁 ，B 线 程 申 请 了 写 锁 ， 正 处 于 等 待 状 态 ， 而 持 有 读 锁 的 A 线 程 再 次 申请 读 锁 ， 就 会 发 
生死 锁 。 














比较 适合 读 写 锁 的 场景 是 : 临界 区 的 大 小 比较 可 观 ， 绝 大 多 数 情况 下 是 读 ， 只 有 非常 少 的 写 。 




















通过 对 互 斥 量 和 读 写 锁 的 讨论 ， 我 们 已 经 有 了 这 种 意识 : 对 于 共享 数据 的 读 写 ， 要 加 锁 保护 。 临 界 区 的 存在 ， 导 致 多 个 线程 不 能 并 行 ， 造 
成 性 能 下 降 。 临 界 区 越 大 ， 多 个 线程 出 入 临界 区 越 频繁 ， 对 性 能 的 伤害 也 就 越 大 。 
































这 种 情况 下 对 性 能 的 伤害 是 比较 明显 的 。 多 线程 情况 下 ， 还 有 一 种 情况 对 性 能 的 损害 是 比较 大 的 ， 却 不 像 临界 区 这 么 明显 。 这 就 是 有 名 的 
伪 共 享 问题 。 





根据 局 部 性 原理 ， 存 储 器 是 分 层 的 ， 如 图 7-21 所 示 。 从 距离 CPU 最 近 的 寄存 器 到 主 内 存 ， 依 次 为 CPU 寄存 器 、L1 Cache、L2 Cache、L3 Cache 
和 主 存 。 从 高 层 往 底层 走 ， 存 储 设 备 变 得 更 慢 ， 容 量 更 大 ， 单 位 字 节 也 更 便宜 。 最 高 层 是 很 少量 的 寄存 器 ， 通 常 可 以 在 1 个 时 钟 周 期 内 访问 它 
们 ， 而 接 下 来 的 LI Cache 通 常 可 以 在 4 个 时 钟 周 期 内 访问 到 ，L2 Cache 通 常 需 要 10 个 时 钟 周期 才能 访问 到 ， 而 到 了 主 存 ， 通 常 需要 几 百 个 时 钟 周 


















































期 才能 访问 得 到 ， 对 这 个 延迟 数据 感 兴趣 的 话 ， 可 以 阅读 一 下 相关 文献 中 | 。 

















在 这 种 分 层 的 存储 结构 中 ， 对 于 每 一 个 k， 位 于 k 层 的 更 快 更 小 的 存储 被 作为 位 于 kt+1 层 的 更 大 更 慢 的 存储 设备 的 缓存 。 换 句 话说 更 快 更 小 的 
存储 设备 的 数据 来 自 更 慢 更 大 的 低 一 级 存储 设备 。 访 问 的 数据 在 高 速 缓 在 中 ， 被 称 为 缓存 命中 ， 这 种 情况 下 访问 速度 比较 快 。 如 果 访 问 的 数据 d 
在 k 级 缓存 中 不 存在 ， 就 不 得 不 从 kr+1 级 中 取出 包含 4 的 那个 块 block) 。 如 果 k 级 缓存 已 经 满 了 的 话 ， 就 可 能 会 覆盖 现存 的 一 个 块 。 




















































容量 更 小 ， 访 问 速度 更 快 ， 
单位 字 节 成 本 更 高 


容量 更 大 ， 更 慢 ， 
单位 字 节 成 本 更 低 





图 7-21 存储 器 的 层次 结构 

















高 一 级 缓存 的 性 能 远 远 超过 低 一 级 的 缓存 ， 所 以 一 旦 缓存 不 命中 (Cache miss) ， 对 性 能 的 损害 就 会 是 比较 大 的 。 












































在 典型 的 多 核 架构 中 ， 每 个 CPU 都 有 自己 的 Cache。 如 果 一 个 内 存 中 的 变量 在 多 个 CPU Cache 中 都 有 副本 ， 则 需要 保证 变量 的 Cache 的 一 致 
性 。 现 在 大 多 数 的 架构 实现 Cache 一 致 性 都 是 采用 MESI 协 议 。 对 缓存 一 致 性 协议 感 兴趣 的 话 ， 可 以 阅读 《计算 机 体系 结构 : 量化 研究 方法 》 这 本 


经 典 之 作 。 此 外 ，Paul E.McKenney 的 《Is Parallel Programming Hard，And，Ifso，What Can You Do About It》 一 书 中 也 有 很 详尽 的 介绍 。 































































































需要 注意 的 是 ，CPU Cache 是 以 缓存 线 〈Cache line〉 为 单位 进行 读 写 的 。 通 常 来 说 ， 一 条 缓存 线 的 大 小 为 64 字 节 。 换 言 之 ， 就 是 访问 1 字 节 
的 数据 ， 系 统 也 会 将 该 字 节 所 在 的 整 条 缓存 线 的 数据 都 搬 到 缓存 中 。 



























































因为 CPU Cache 具 有 以 Cache line 为 单位 进行 读 写 的 性 质 ， 所 以 在 多 线程 编程 中 ， 稍 有 不 慎 ， 就 会 掉 入 伪 共 享 的 陷阱 ， 造 成 性 能 恶化 。 

















可 以 考虑 下 如 下 代码 : 
int suml; 
int sum2; 
void threadl (int v[], int v count) {suml = 0;for (int i = 0; i < Vv count; i++) suml += Vv[il]; 
} 
void thread2 (int w[le int w count) { sum2 = 07 for (int i = 0; i < Y eount} i++) sum2 += v[i]; 
, 




















这 部 分 代码 定义 了 两 个 全 局 变量 suml 和 sum2， 两 个 线程 分 别 将 计算 结果 放 入 各 自 的 全 局 变量 中 ， 看 起 来 并 行 不 悖 。 但 是 由 于 这 两 个 全 局 变 
量 紧 挨 着 定义 ， 编 译 器 给 这 两 个 变量 分 配 的 内 存 几乎 总 是 紧 挨 着 的 ， 因 此 这 两 个 变量 很 可 能 在 同一 条 Cache line 中 。 


















































此 sum2 的 值 也 随同 suml 一 并 被 加 载 





By 











如 图 7-22 所 示 ， 尽 管线 程 1 所 在 的 CPU 并 不 需要 sum2 的 值 ， 但 是 由 于 sum2 和 suml 在 同一 条 Cache line 中 ， 
到 了 thread1 所 在 CPU 的 Cache 中 了 。 
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threadl 





ll | 


thread2 


aa | 






































图 7-22” 伪 共享 








可 以 想见 ， 就 因为 两 个 值 彼此 毗邻 ， 落 在 同一 条 Cache line 中 ， 会 导致 大 量 的 缓存 不 命中 ， 从 而 影响 性 能 。 


下 面 通 过 一 个 例子 ， 来 看 伪 共 享 给 性 能 
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计算 圆周 率 x 有 一 种 方法 是 数值 积分 法 : 














来 的 影响 。 


TT =| -ar 
1 夺 吕 志和 


可 以 通过 基于 中 点 矩形 的 数值 积分 方法 来 求解 上 述 积 分 ， 如 下 : 























4thread1 修 改 suml 的 值 时 ， 尽 管 并 未 更 新 sum?2 的 值 ， 但 影响 的 是 整 条 Cache line， 它 会 将 thread2 所 在 CPU 对 应 的 Cache line 置 为 Invalidate。 如 
果 thread2 尝 试 更 新 sum2， 会 触发 缓存 不 命中 。 反 过 来 ，thread2 修 改 sum2 时 ， 也 会 影响 到 suml 的 缓存 命中 。 





static long num rect = 400000000; 
double mid = 0.07 
double height = 0.0; 
double width = 1.0/((double)num rect); 
int cur } 
for (cur = 0;cur < num rect; cur += 1) 
{ 

mid = (cur+0.5)*width; 

height = 4.0/(1 + mid*mid); 

sum += height; 
} 
Sum *= width; 












































这 是 典型 的 计算 密集 型 程序 ， 因 此 我 们 采用 多 线程 来 分 工 协 作 ， 代 码 如 下 : 























#include <stdlib.h> 

#include <stdio.h> 

#include <pthread.h> 

#define NR THREAD 1 

static long num rect = 400000000; 
typedef struct sum struct { 


double sum; 
//char padding[8]; 


} sum struct; 
struct sum struct _ sum[NR THREAD]; 
void* calc pi (void* ptr) 


{ 


int index = (int)ptr; 
double mid = 0.0; 
double height = 0.0; 
double width = 1.0/((double)num rect); 
int cur = index; 和 
for(;cur < num rect; cur += NR_THREAD) 
{ 

mid = (cur+0.5)*width; 

height = 4.0/(1 + mid*mid); 

__ sum[index] .sum += height; 
} 


_ sum[index] .sum *= width; 
main() 


int i = 0 

int ret 2? 

double result = 0.0; 
pthread t tid[NR THREAD]; 


fprintf (stdout, "the size of struct sum struct = %ld\n",sizeof(struct sum struct)); 


for(i=0 ;i< NR THREAD; i++) 
{ 


_ sum[i].sum = 0.0; 


ret = pthread create (gtid[i],NULL,calc pi, (void*) i); 


if(ret != 0) 

{ 
/*error handle here*/ 
二 位》 


for( i = 0; i < NR THREAD ; i++) 


pthread join(tiqd([il],NULL); 
result += _ sum[i].sum; 


} 
fprintf (stdout, "the PI = $%.32f\n",result); 
return 0; 


























为 mum rect 等 于 4 亿 ， 因 此 要 计算 4 亿 次 ， 可 以 通 

















过 修改 NR_THREAD 的 值 ， 让 8 个 线程 协同 计算 ， 最 后 将 结果 累加 到 一 起 得 到 了 





E 确 的 值 ， 希 





望 这 样 能 将 执行 时 间 缩 短 为 单线 程 的 118， 如 图 7-23 所 示 。 


























线程 0 | 0 | 8 16 | 师 | 攻 
线程 1 1 9 17 | 和 | | 
线程 7 15 23 








图 7-23 ”8 个 线程 并 发 计算 的 值 












































I 





因为 每 个 线程 都 要 负责 往 。_sum 对 应 的 位 置 更 新 结果 。 因 此 这 个 数组 很 容易 触发 前 面 提 到 的 伪 共 享 陷 阱 。 当 sum_struct 结 构 体 没有 填充 字符 
时 ， 该 结构 体 占 据 8 字 节 ， 当 8 个 线程 并 发 时 ，_ sum 数 组 很 可 能 在 同一 个 Cache line 中 ， 这 时 候 性 能 必然 会 受到 影响 。 为 了 避 开 false sharing 这 个 陷 
阱 ， 测 试 程序 采用 了 加 填充 字 节 的 方法 。 如 果 给 sum_struct 结 构 体 加 上 56 个 填充 字 节 ， 每 个 sum_struct 占 据 1 条 Cache line 的 大 小 ， 则 可 以 确保 它们 
之 间 不 会 互相 影响 。 













































































证 


typedef struct sum struct { 
double sum ;/*padding 56 字 节 ， 占 满 


1 条 


Cache line*/ 
//char padding[56]; 
} sum struct; 
struct sum struct _ sum[NR THREAD]; 





在 24 核 的 服务 器 上 运行 ， 结 果 如 表 7-14 所 示 。 








表 7-14” 伪 共享 测试 代码 的 运行 结果 


‘, 


| 运行 时 间 
测试 场景 
基 程 0m10.306s 0m10.308s 0m0.004s 
8 个 线程 (没有 padding) 0m6.663s 0m49.976s 0m0.004s 
8 个 线程 (padding 56 字 节 ) 0m1.297s 0m10.324s 0m0.008s 


可 以 看 出 ， 如 果 不 加 56 字 节 的 填充 ， 由 于 伪 共 享 引起 的 大 量 缓存 不 命中 ，8 个 线程 并 没有 带 来 8 倍 的 效率 提升 。 通 过 填充 字 节 解决 了 伪 共 
的 问题 之 后 ， 效 率 线性 地 提升 了 8 倍 。 
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[1] http://www.sisoftware.net/?d=qa& 人 =ben mem latency。 
[2] Latency Number Every Programmer Should Know。 


7.10 ”条件 等 待 


条 件 等 待 是 线程 间 同 步 的 另 一 种 








线程 经 常 遇 到 这 种 情况 : 要 想 继 
就 是 等 待 ， 等 到 条 件 满足 为 止 。 通 各 
型 。 当 另外 一 个 线程 发 现 条 件 符合 的 


种 可 能 性 ， 一 种 是 唤醒 一 个 线程 ， 一 


Ck 

















就 像 工 厂 里 生产 车 间 没 有 原料 了 
原料 ， 如 果 原 料 充足 ， 你 会 发 广播 给 
一 个 车 间 开 工 的 ， 你 可 能 只 会 通知 一 

















为 什么 要 有 条 件 等 待 ? 考虑 生产 
应 该 停工 等 待 ， 一 直 等 到 队列 不 空 为 





方法 。 


续 执行 ， 可 能 要 依赖 某 种 条 件 。 如 果 条 件 不 满足 ， 它 能 做 的 事情 
条 件 的 达成 ， 很 可 能 取决 于 另 一 个 线程 ， 比 如 生产 者 -消费 者 模 
时 候 ， 它 会 选择 一 个 时 机 去 通知 等 竺 在 这 个 条 件 上 的 线程 。 有 两 
种 是 广播 ， 唤 醒 其 他 线程 。 














， 所 有 生产 车 间 都 停工 了 ， 工 人 们 都 在 车 间 睡 觉 。 突 然 进 来 一 批 
所 有 车间， 原料 来 了 ， 快 来 开工 吧 。 如 果 进 来 的 原料 很 少 ， 只 够 
个 车 间 开 工 。 














者 -消费 者 模型 ， 如 果 任务 队列 处 于 空 的 状态 ， 那 么 消费 者 线程 就 
止 。 如 果 没 有 条 件 等 待 ， 那 么 消费 者 线程 的 代码 可 能 会 写成 这 











pthread mutex t m = PTHREAD MUTEX INITIALIZER; 


int WaitEorTrue () 


pthread mutex lock(&m); 


while (condition is false) // 条 件 不 满足 


{ 


Pthread mutex_unlock (&m) ; / /解锁 等 待 其 他 线程 改变 共享 数据 


sleep (n) ; / /睡眠 


nn 秒 后 再 次 加 锁 验 证 条 件 是 否 满足 


pthread mutex lock(&m); 








如 果 条 件 不 满足 ， 就 只 能 睡眠 。 
虑 如 下 场景 : 解锁 之 后 ，sleep 之 前 ， 








很 自然 需要 这 么 一 种 机 制 : 线程 


需要 这 人 么 
线程 在 此 处 等 待 ， 等 待 条件 的 满足 ; 





上 面 的 代码 虽然 也 能 满足 这 个 要 求 ， 但 存在 严重 的 效率 问题 。 考 
等 待 的 条 件 突然 满足 了 ， 但 很 不 幸 ， 该 线程 仍然 会 睡眠 n 秒 。 








在 条 件 不 满足 的 情况 下 ， 主 动 让 出 互 斥 量 ， 让 其 他 线程 去 折腾 ， 
一 旦 条 件 满 足 ， 线 程 就 可 以 立刻 被 唤醒 。 线 程 之 所 以 可 以 安心 等 

















等， 依赖 的 是 其 他 线程 的 协作 ， 它 站 





信 会 有 一 个 线程 在 发 现 条 件 满 足以 后 ， 将 向 它 发 送信 号 ， 并 且 让 





出 互 斥 量 。 如 果 其 他 线程 不 配合 《不 发 信号 ， 不 让 出 互 斥 量 ) ， 这 个 主动 让 出 互 斥 量 并 等 待 事件 发 生 
的 线程 就 真 的 要 等 到 人 花 儿 都 谢 了 。 














7.10.1 条 件 变 量 的 创建 和 销毁 








NPTL 使 用 pthread_cond t 类 型 的 变量 来 表示 条 件 变 量 。 条 件 变 量 不 是 一 个 值 ， 我 们 无 法 给 条 件 变量 
赋值 。 一 个 线程 如 果 要 等 待 某 个 事件 的 发 生 ， 或 者 某 个 条 件 的 满足 ， 那 么 这 个 线程 需要 的 是 条 件 变 
量 : 线程 等 竺 在 条 件 变量 上 。 

















和 互 斥 锁 一 样 ， 条 件 变量 在 使 用 之 前 要 先 初始 化 。 互 斥 锁 有 静态 初始 化 ， 条 件 变量 也 一 样 。 简 单 
地 把 PTHREAD_ COND INITIALIZER 赋 值 给 pthread_cond t 类 型 的 变量 就 可 完成 条 件 变 量 的 初始 化 : 





pthread cond t cond = PTHREAD COND INITIALIZER; 








动态 分 配 条 件 变 量 ， 或 者 对 条 件 变 量 的 属性 有 所 定制 ， 都 需要 用 pthread_cond init 进 行 初始 化 : 





int pthread cond init (pthread cond 七 xcond， 
const pthread condattr t *attr); 





如 果 采 用 默认 属性 ， 可 以 将 NULL 作 为 第 二 个 参数 。 











对 于 pthread_cond init 初 始 化 的 条 件 变量 ， 不 要 瑟 记 调用 pthread_cond destroy 来 销毁 。 其 接口 定义 
如 下 : 





int pthread cond destroy(pthread cond 七 xcond) ; 





对 于 条 件 变 量 的 初始 化 和 销毁 ， 需 要 注意 以 下 几 点 : 


:永远 不 要 用 一 个 条 件 变量 对 另 一 个 条 件 变量 赋值 ， 即 pthread_cond tcond b=cond a 不 合法 ， 这 种 
行为 是 未 定义 的 。 








.使 用 PTHREAD_COND _JINITIALIZE 静 态 初 始 化 的 条 件 变量 ， 不 需要 被 销毁 。 
.要 调用 pthread_cond destroy 销 毁 的 条 件 变量 可 以 调用 pthread_cond init 重 新 进行 初始 化 。 
:不 要 引用 已 经 销毁 的 条 件 变 量 ， 这 种 行为 是 未 定义 的 。 


有 了 条 件 变量 的 初始 化 和 销毁 ， 就 可 以 进入 正题 了 。 接 下 来 看 看 如 何 使 用 条 件 变量 。 


7.10.2 条件 变量 的 使 用 











条 件 变 量 ， 天 生 就 是 与 条 件 的 满足 与 否 相伴 而 生 的 。 通 常 ， 线 程 会 对 一 个 条 件 进 行 测试 ， 如 果 条 
件 不 满足 ， 就 等 待 (pthread_cond_wait) ， 或 者 等 待 一 段 有 限 的 时 间 〈pthread_cond_timedwait) 。 相 关 
函数 的 定义 如 下 : 








int pthread cond wait (pthread cond t *restrict cong, 
pthread mutex t *restrict mutex); 

int pthread cond timedwait (pthread cond t *restrict cong, 
pthread mutex t *restrict mutex, 
const struct timespec *restrict abstime); 


从 接口 上 可 以 看 出 ， 条 件 等 待 总 是 和 互 斥 量 绑 定 在 一 起 的 。 为 什么 要 这 样 设计 ? 





条 件 等 竺 是 线程 间 同 步 的 一 种 手段 ， 如 果 只 有 一 个 线程 ， 条 件 不 满足 ， 那 么 等 待 干 年 也 是 枉然 ， 
所 以 必须 要 有 一 个 线程 通过 茶 些 操作 ， 改 变 共享 数 据 ， 使 原先 不 满足 的 条 件 变 得 满足 了 ， 并 且 友 好 地 
通知 等 竺 在 条 件 变量 上 的 线程 。 

















条 件 不 会 无 缘 无 故地 突然 变 得 满足 了 ， 必 然 会 牵扯 到 共享 数据 的 变化 。 所 以 一 定 要 有 互 斥 锁 来 保 
护 。 没 有 互 斥 锁 ， 就 无 法 安全 地 获取 和 修改 共享 数据 。 





好 吧 ， 就 算 如 此 ， 先 调用 pthread mutex lock， 发 现 条 件 不 满足 ， 解 锁 ， 然 后 等 待 在 条 件 上 就 行 
了 ， 为 什么 还 要 把 互 斥 锁 作为 参数 传 给 pthread_cond_ wait 呢 ? 像 下 面 所 示 代 码 这 样 使 用 不 可 以 吗 ? 


/ /错误 的 设计 


pthread mutex lock (&m) 
while (condition is_ false) 
{ 
pthread mutex unlock (&m); 
/ /解锁 之 后 ， 等 待 之 前 ， 可 能 条 件 已 经 满足 ， 信 号 已 经 发 出 ， 但 是 该 信号 可 能 会 被 错过 


cond wait (&cV) ; 
pthread mutex lock(&m); 
} 





原因 在 于 ， 上 面 的 解锁 和 等 待 不 是 原子 操作 。 解 锁 以 后 ， 调 用 cond_wait 之 前 ， 如 果 已 经 有 其 他 线 
程 获取 到 了 互 斥 量 ， 并 且 满 足 了 条 件 ， 同 时 发 出 了 通知 信号 ， 那 么 cond_wait 将 错过 这 个 信号 ， 可 能 会 
导致 线程 永远 处 于 阻塞 状态 。 所 以 解锁 加 等 待 必 须 是 一 个 原子 性 的 操作 ， 以 确保 已 经 注册 到 事件 的 等 
符 队 列 之 前 ， 不 会 有 其 他 线程 可 以 获得 互 斥 量 。 

















那 先 注册 等 待 事件 ， 后 释放 锁 不 行 吗 ? 注意 ， 条 件 等 竺 是 个 阻塞 型 的 接口 ， 不 单单 是 注册 在 事件 
的 等 待 队列 上 ， 线 程 也 会 因此 阻塞 于 此 ， 从 而 导致 互 斥 量 无 法 释放 ， 其 他 线程 获取 不 到 互 斥 量 ， 也 就 








无 





法 通过 改变 共享 数据 使 等 待 的 条 件 得 到 满足 ， 因 此 这 就 造成 了 和 死 锁 。 


下 面 的 伪 代 码 显示 了 POSIX 如 何 使 用 条 件 变 量 v 和 互 斥 量 m 来 等 待 条 件 的 发 生 : 


pthread mutex lock(&m); 
while(condition is false) 
pthread cond wait (&v, &m) ; // 此 处 会 阻塞 


/* 如 果 代码 运行 到 此 处 ， 则 表示 我 们 等 待 的 条 件 已 经 满足 了 ， 


* 并 且 在 此 持 有 了 互 斥 量 


* 
/* 在 满足 条 件 的 情况 下 ， 做 你 想 做 的 事情 。 


4 
pthread mutex unlock (&m); 


pthread_cond_wait 函 数 只 能 由 拥有 互 斥 量 的 线程 来 调用 ， 当 该 函数 返回 的 时 候 ， 系 统 会 确保 该 线程 

















再 次 持 有 互 斥 量 ， 所 以 这 个 接口 容易 给 人 一 种 误解 ， 就 是 该 线程 一 直 在 持 有 互 斥 量 。 事 实 上 并 不 是 这 
样 的 。 这 个 接口 向 系统 声明 了 我 的 心 在 等 待 ， 永 远 在 等 竺 之后， 就 把 互 斥 量 给 释放 了 。 这 样 其 他 线程 
就 有 机 会 持 有 互 斥 量 ， 操 作 共享 数据 ， 触 发 变化 ， 使 线程 等 待 的 条 件 得 到 满足 。 



































既然 互 斥 量 和 条 件 变 量 关 系 如 此 紧密 ， 为 什么 不 干脆 将 互 斥 量变 成 条 件 变量 的 一 部 分 呢 ? 原因 











是 ， 同 一 个 互 斥 量 上 可 能 有 不 同 的 条 件 变量 ， 比 如 说 ， 有 的 线程 希望 队列 不 空 的 时 候 发 送信 号 ， 有 的 
线程 希望 队列 满 的 时 候 发 送 通知 给 它 《〈“ 为 了 创建 更 多 的 线程 做 消费 者 或 其 他 目的 ) 。 

















pthread_cond_ timedwait 函 数 与 pthread_cond_wait 的 工作 方式 几乎 是 一 样 的 ， 只 是 调用 时 需要 指定 一 





个 超时 的 时 间 。 注 意 这 个 时 间 是 绝对 时 间 ， 而 不 是 相对 时 间 。 如 果 最 多 等 待 2 分 钟 ， 那 么 这 个 值 应 该 是 
当前 时 间 加 上 2 分 钟 。 


上 面 将 互 斥 量 和 条 件 变 量 配合 使 用 的 示范 代码 中 有 个 很 有 意思 的 地 方 ， 就 是 用 了 while 语 句 ， 醒 来 











之 后 要 再 次 判断 条 件 是 否 满足 。 





while(condition is false) 
pthread _conqd wait (&v, &m) ; / /此 处 会 阻塞 


为 什么 不 写成 ; 


ifE(condition is false) 
pthread cond wait (&vV, &m) ; // 此 处 会 阻塞 


唤醒 以 后 ， 再 次 检查 条 件 是 否 满足 ， 是 不 是 多 此 一 举 ? 





答案 是 不 得 不 如 此 。 因 为 唤醒 中 存在 虚假 唤醒 (spurious wakeup) ， 换 言 之 ， 条 件 尚 未 满 
足 ，pthread_cond_wait 就 返回 了 。 在 一 些 实现 中 ， 即 使 没有 其 他 线程 向 条 件 变量 发 送信 号 ， 等 待 此 条 件 
变量 的 线程 也 有 可 能 会 醒 来 。 


-> 














看 起 来 这 像 是 个 bug， 但 它 是 实 实在 在 存在 的 。 为 什么 会 存在 虚假 唤醒 ? 一 个 原因 是 
pthread_cond_wait 是 futex 系 统 调用 ， 属 于 阻塞 型 的 系统 调用 ， 当 系统 调用 被 信号 中 断 的 时 候 ， 会 返回 - 
1， 并 且 把 errno 置 为 EINTR。 很 多 这 种 系统 调用 为 了 防止 被 信号 中 断 都 会 重启 系统 调用 ， 代 码 如 下 : 











pid t r wait(int *stat loc) 

{ 
int retval; 
while(((retval = wait(stat loc)) ==-1 && (errno == EINTR)); 
return retval; 


} 





但 是 futex 不 一 样 ， 在 futex 返 回 之 后 ， 到 重启 系统 调用 之 前 ， 可 能 已 经 调用 过 pthread_cond signal 或 
pthread cond broadcast。 一旦 错失 ， 再 次 调用 pthread_cond wait 可 能 就 会 导致 无 限制 地 等 待 下 去 。 为 了 
防止 这 种 情况 ， 宁 可 虚假 唤醒 ， 也 不 能 再 次 调用 pthread_cond_wait， 以 免 陷 入 无 穷 的 等 待 中 。 














除了 上 面 的 信号 因素 外 ， 还 存在 以 下 情况 : 条 件 满足 了 发 送信 号 ， 但 等 到 调用 pthread_cond_wait 的 
线程 得 到 CPU 资源 时 ， 条 件 又 再 次 不 满足 了 。 好 在 无 论 是 哪 种 情况 ， 醒 来 之 后 再 次 测试 条 件 是 否 满足 
就 可 以 解决 虚假 等 待 的 问题 。 








条 件 等 待 ， 等 于 把 控制 权 交 给 了 别 的 线程 ， 它 信任 别 的 线程 会 在 合适 的 时 机 通知 它 ， 这 是 多 大 的 
信任 啊 。 如 果 其 他 线程 忘记 发 送信 号 了 ， 那 么 条 件 等 待 的 线程 就 彻底 “悲剧 ”了 。 

















如 何 发 送信 号 来 通知 等 待 的 线程 呢 ?POSIX 提 供 了 如 下 两 个 接口 : 


int pthread cond signal (pthread cond t *cond); 
int pthread cond broadcast (pthread cond 七 xcond) ; 





pthread_cond_signal 人 负责 唤醒 等 待 在 条 件 变 量 上 的 一 个 线程 ，pthread_cond_broadcast， 顾 名 思 义 ， 
就 是 广播 唤醒 等 待 在 条 件 变 量 上 的 所 有 线程 。 














等 一 下 ， 刚 才 讲 解 pthread_cond_wait 的 时 候 曾 提 到 过 ， 线 程 醒 来 时 会 确保 持 有 互 斥 量 ， 为 何 广播 还 











能 唤醒 等 竺 在 条 件 变 量 上 的 所 有 线程 呢 ， 不 是 前 后 矛盾 吗 ? 





答案 是 不 矛盾 ， 所 有 的 线程 被 广播 唤醒 了 之 后 ， 集 体 争夺 互 斥 锁 ， 没 抢 到 的 继续 睡 。 从 内 核 中 醒 
来 ， 然 后 继续 睡 去 ， 是 一 种 性 能 的 浪费 。 








使 用 通知 机 制 来 完成 线程 同步 ， 代 码 范例 如 下 : 


/ /为 让 流程 更 加 清晰 ， 此 处 忽略 了 


error handle 
pthread mutex lock(&m); 
/* 一 些 对 共享 数据 的 操作 ， 会 导致 男 一 个 线程 等 待 的 条 件 满足 


站 
/ /此 处 也 可 以 是 


Pthread_conq_ proadcast 函 数 


pthread cond _ signal (&cond); 
pthread mutex unlock (&m); 


发 送信 号 ， 通 知 等 待 在 条 件 上 的 线程 ， 然 后 解锁 互 斥 量 。 








注意 范例 代码 中 先 发 送 信号 ， 然 后 解锁 互 斥 量 ， 这 个 顺序 不 是 必须 的 ， 也 可 以 颠倒 。 标 准 允 许 任 
意 顺 序 执行 这 两 个 调用 。 





有 什么 区 别 吗 ? 











先 通知 条 件 变量 、 后 解锁 互 斥 量 ， 效 率 会 比 先 解锁 、 后 通知 条 件 变 量 低 。 因 为 先 通知 后 解锁 ， 执 
行 pthread_cond_wait 的 线程 可 能 在 互 斥 量 已 然 处 于 加 锁 状 态 的 时 候 醒 来 ， 发 现 互 斥 量 仍然 没有 解锁 ， 就 
会 再 次 休眠 ， 从 而 导致 了 多 余 的 上 下 文 切 换 。 某 些 实现 使 用 等 待 变形 (wait morphing) 来 优化 这 个 问 
题 : 并 不 真正 地 唤醒 执行 pthread_cond_wait 的 线程 ， 而 是 将 线程 从 条 件 变量 的 等 待 队列 转移 到 互 斥 量 的 
等 待 队 列 上 ， 从 而 消除 无 谓 的 上 下 文 切 换 。 


























glibc 对 pthread_cond_ broadcast 做 了 类 似 的 优化 ， 即 只 唤醒 一 个 线程 ， 将 其 他 线程 从 条 件 变量 的 等 待 
队列 搬移 到 了 互 斥 量 的 等 待 队 列 中 。 对 实现 细节 感 兴趣 的 可 以 参阅 Ulrich Drepper 的 《Futexes Are 
Tricky》 。 














先 解 锁 、 后 通知 条 件 变量 虽然 可 能 会 有 性 能 上 的 优势 ， 但 是 也 会 带 来 其 他 的 问题 。 如 果 存 在 一 个 
高 优先 级 的 线程 ， 既 等 竺 在 互 太 量 上 ， 也 等 竺 在 条 件 变 量 上 ， 同 时 还 存在 一 个 低 优先 级 的 线程 ， 只 等 








符 在 互 斥 量 上 。 一 旦 先 解锁 互 太 量 ， 低 优先 级 的 进程 就 可 能 会 抢先 获得 互 太 量 ， 待 调用 
pthread_cond_signal 之 后 ， 高 优先 级 的 进程 会 发 现 互 斥 量 已 经 被 低 优先 级 的 进程 抢 走 了 。 

















第 8 章 ”理解 Linux 线 程 (2) 





要 ， 掌 握 了 这 些 基 本 接口 ， 就 能 应 对 绝 大 多 数 





第 7 章 介 绍 了 线程 的 基本 接口 ， 这 些 基 本 接口 非常 
的 应 用 场景 。 本 章 将 介绍 一 些 线程 相关 的 其 他 内 容 。 


8.1 线程 取消 


线程 可 以 通过 调用 pthread_cancel 函 数 来 请 求 取 消 同一 进程 中 的 其 他 线程 。 











从 编程 的 角度 来 讲 ， 不 建议 使 用 这 个 接口 。 笔 者 对 该 接口 的 评价 不 高 ， 该 接口 实现 了 一 个 似 是 而 
非 的 功能 ， 却 引入 了 一 堆 问 题 。 陈 借 在 《Linux 多 线程 服务 嚣 编程》 一 书 中 也 提 到 过 ， 不 建议 使 用 取消 
接口 来 使 线程 退出 ， 个 人 表示 十 分 赞同 。 











8.1.1 函数 取消 接口 











Linux 提 供 了 如 下 函数 来 控制 线程 的 取消 : 





int pthread cancel (pthread t thread); 





一 个 线程 可 以 通过 调用 该 函数 向 另 一 个 线程 发 送 取 消 请 求 。 这 不 是 个 阻塞 型 接口 ， 发 出 请 求 后 ， 
函数 就 立刻 返回 了 ， 而 不 会 等 待 目标 线程 退出 之 后 才 返 回 。 














如 果 成 功 ， 该 函数 返回 0， 和 否则 将 错误 码 返 回 。 











对 于 glibc 实 现 而 言 ， 调 用 pthread_cancel 时 ， 会 向 目标 线程 发 送 一 个 SIGCANCEL 的 信号 ， 该 信号 就 


是 6.4 节 “信号 的 分 类 ”中 提 到 的 被 NPTL 征 用 的 32 号 信号。 





线程 收 到 取消 请 求 后 ， 会 采取 什么 行动 呢 ? 这 取决 于 该 线程 的 设 定 。NPTL 提 供 了 函数 来 设置 线程 
是 否 允 许 取 消 ， 以 及 在 允许 取消 的 情况 下 ， 如 何 取消 。 








pthread_setcancelstate 函 数 用 来 设置 线程 是 否 允 许 取消 ， 函 数 定 义 如 下 : 
int pthread setcancelstate (int state, int *oldstate) 


state 参 数 有 两 种 可 能 的 值 : 





:PTHREAD CANCEL ENABLE? 
:PTHREAD CANCEL DISABLE 


如 果 取 消 状态 是 PTHREAD CANCEL DISABLE， 则 表示 线程 不 理会 取消 请 求 ， 取 消 请 求 会 被 暂时 
挂 起 ， 不 予 处 理 。 




















线程 的 默认 取消 状态 是 PTHREAD CANCEL ENABLE。 如 果 state 是 
PTHREAD_CANCEL ENABLE， 那 么 收 到 取消 请 求 后， 会 发 生 什么 ”这 取决 于 线程 的 取消 类 型 。 
pthread_setcanceltype 函 数 用 来 设置 线程 的 取消 类 型 ， 其 定义 如 下 : 

















int pthread setcanceltype (int type, int *oldtype); 


取消 类 型 有 两 种 值 : 





‘PTHREAD CANCEL DEFERRED 


:PTHREAD CANCEL ASYNCHRONOUS 








PTHREAD_CANCEL ASYNCHRONOUS 为 异步 取消 ， 即 线程 可 能 在 任何 时 间 点 〈 可 能 是 立即 取 
消 ， 但 也 不 一 定 ) 取消 线程 。 这 种 取消 方式 的 最 大 问题 在 于 ， 你 不 知道 取消 时 线程 执行 到 了 哪 一 
所 以 ， 这 种 取消 方式 太 粗 暴 ， 很 容易 造成 后 续 的 混乱 。 因 此 不 建议 使 用 该 取消 方式 。 











PTHREAD_CANCEL DEFERRED 是 延迟 取消 ， 线 程 会 一 直 执行 ， 直 到 遇 到 一 个 取消 点 ， 这 种 方式 
也 是 新 建 线程 的 默认 取消 类 型 。 











什么 是 取消 点 ?就 是 对 于 某 些 函数 ， 如 果 线 程 允许 取消 且 取 消 类 型 是 延迟 取消 ， 并 且 线程 也 收 到 
了 取消 请 求 ， 那 么 当 执行 到 这 些 函数 的 时 候 ， 线 程 就 可 以 退出 了 。 











标准 规定 了 很 多 函数 必须 是 取消 点 ， 由 于 太 多 (有 好 几 十 个 之 多 ) ， 就 不 一 一 罗列 了 ， 通 过 man 
pthreads 可 以 查询 到 这 些 取 消 点 函数 。 





























线程 执行 到 取消 点 ， 会 自动 处 理 取消 请 求 ， 但 是 如 果 线 程 没有 用 到 任何 取消 点 函数 ， 那 该 怎么 
办 ， 如 何 响应 取消 请 求 ? 




















为 了 应 对 这 种 场景 ， 系 统 引 入 了 pthread testcancel 函 数 ， 该 函数 一 定 是 取消 点 。 所 以 编程 者 可 以 周 
期 性 地 调用 该 函数 ， 只 要 有 取消 请 求 ， 线 程 就 能 响应 。 该 函数 定义 如 下 : 














void pthread testcancel (void); 











如 果 线 程 被 取消 ， 并 且 其 分 离 状态 是 可 连接 的 ， 那 么 需要 由 其 他 线程 对 其 进行 连接 。 连 接 之 
后 ，pthread join 函数 的 第 二 个 参数 会 被 置 成 PTHREAD_ CANCELED， 通 过 该 值 可 以 知道 线程 并 不 是 “ 寿 
终 正 宫 ”， 而 是 被 其 他 线程 取消 而 导致 的 退出 。 























接口 都 介绍 完了 ， 是 时 候 讨 论 下 线程 取消 的 浆 端 了 。 线 程 取 消 是 一 种 在 线程 的 外 部 强行 终止 线程 
的 执行 做 法 ， 由 于 无 法 预知 目标 线程 内 部 的 情况 ， 尤 其 是 第 一 种 异步 取消 类 型 ， 因 此 可 能 会 带 来 毁灭 
性 的 结果 。 






































目标 线程 可 能 会 持 有 互 斥 量 、 信 和 号 量 或 其 他 类 型 的 锁 ， 这 时 候 如 果 收 到 取消 请 求 ， 并 且 取 消 类 型 
是 异步 取消 ， 那 么 可 能 目标 线程 掌握 的 资源 还 没有 来 得 及 释放 就 被 迫 退 出 了 ， 这 可 能 会 给 其 他 线程 带 
来 不 可 恢复 的 后 果 ， 比 如 死 锁 《其 他 线程 再 也 无 法 获得 资源 ) 。 



































即使 执行 好 步 取消 也 安然 无 盖 的 函数 称 为 异步 取消 安全 函数 〈async-cancel-safe fonction) ， 手 册 里 
说 只 有 下 述 三 个 函数 是 异步 取消 安全 函数 ， 所 以 对 于 其 他 函数 ， 一 律 都 不 是 异步 取消 安全 函数 。 








pthread cancel () 
pthread setcancelstate () 
pthread setcanceltype() 








所 以 对 编程 人 员 而 言 ， 应 该 遵循 以 下 原则 : 








:第 一 ， 轻 易 不 要 调用 pthread_cancel 函 数 ， 在 外 部 杀 死 线程 是 很 糟糕 的 做 法 ， 毕 兑 如 果 想 通知 目标 
线程 退出 ， 还 可 以 采取 其 他 方法 。 


























第 二 ， 如 果 不 得 不 允许 线 程 取消 ， 那 么 在 某 些 非常 关键 不 容 有 失 的 代码 区 域 ， 暂 时 将 线程 设置 成 
不 可 取消 状态 ， 退 出 关键 区 域 之 后 ， 再 恢复 成 可 以 取消 的 状态 。 





第 三 ， 在 非 关 键 的 区 域 ， 也 要 将 线程 设置 成 延迟 取消 ， 永 远 不 要 设置 成 异步 取消 。 








8.1.2 ”线程 清理 函数 





假设 遇 到 取消 请 求 ， 线 程 执行 到 了 取消 点 ， 却 没有 来 得 及 做 清理 动作 《〈 如 动态 申请 的 内 存 没 有 释 
放 ， 申 请 的 互 斥 量 没有 解锁 等 ) ， 可 能 会 导致 错误 的 产生 ， 比 如 和 死 锁 ， 甚 至 是 进程 裔 演 。 














下 面 来 看 一 个 简单 的 例子 : 





void* cancel unsafe (voidqx) { 
static pthread mutex t mutex = PTHREAD MUTEX INITIALIZER; 
pthread mutex lock(&mutex); // 此 处 不 是 撤消 点 


struct timespec ts = {3, 0}; 


nanosleep (&ts, 0); / / 是 撤消 点 
pthread mutex unlock (&mutex); // 此 处 不 是 撤消 点 
return 0; 


int main(void) { 
pthread t t; 
pthread createl(&t, 
pthread cancel (t); 
pthread join(t, 0); 
cancel unsafe (0); // 发 生死 锁 ! 


0, cancel unsafe, 0); 





return 0; 








在 上 面 的 例子 中 ，nanosleep 是 取消 点 ， 如 果 线 程 执行 到 此 处 时 被 其 他 线程 取消 ， 就 会 出 现 以 下 情 
况 : 互 斥 量 还 没有 解锁 ， 但 持 有 锁 的 线程 已 不 复 存 在 。 这 种 情况 下 其 他 线程 再 也 无 法 申请 到 互 斥 量 ， 
很 有 可 能 在 某 处 就 会 陷入 死 锁 的 境地 。 





过 














为 了 避免 这 种 情况 ， 线 程 可 以 设置 一 个 或 多 个 清理 函数 ， 线 程 取消 或 退出 时 ， 会 自动 执行 这 些 清 
里 函数 ， 以 确保 资源 处 于 一 致 的 状态 。 其 相关 接口 定义 如 下 : 











Vi 








void pthread cleanup push(void (*routine) (void *),void *arg); 
void pthread cleanup Pop (int execute); 


标准 允许 用 宏 (macro) 来 实现 这 两 个 接口 ，Linux 就 是 用 宏 来 实现 的 。 这 意味 着 这 两 个 函数 必须 同 
时 出 现 ， 并 且 属 于 同一 个 语法 块 。 








何 为 同一 个 语法 块 ? 比较 难 解 释 ， 我 尝试 来 解释 一 下 它 的 反面 。 如 果 两 个 函数 在 不 同 的 函数 中 出 
现 ， 它 们 就 不 是 处 于 同一 个 语法 块 。 示 例 代 码 如 下 : 











这 个 例子 比较 简单 ， 因 为 pthread_cleanup_push 在 线程 的 主 函 数 里 面 ， 而 pthread_cleanup_ pop 在 另外 
一 个 函数 里 面 ， 这 一 对 函数 明显 不 在 一 个 语法 块 里 面 。 














上 面 这 种 错误 是 很 好 防范 的 ， 比 较 难 防范 的 是 下 面 这 种 : 


pthread cleanup push(clean func,clean arg); 


pthread cleanup pop (0); 








在 日 常 编码 中 很 容易 犯 上 面 这 种 错误 。 因 为 pthread_cleanup_push 和 和 phtread_cleanup_pop 的 实现 中 包 
含 了 {和 }， 所 以 将 pop 放 入 if 引 的 代码 块 中 ， 会 导致 括号 匹配 错乱 ， 最 终 会 引发 编译 错误 。 











第 二 个 需要 注意 的 是 ， 可 以 注册 多 个 清理 函数 ， 如 下 所 示 : 





pthread cleanup push(clean func 1,clean arg 1) 
pthread cleanup push(clean func 2,clean arg 2) 








pthread cleanup pop (execute 2); 
pthread cleanup Pop (execute 1); 








从 push 和 pop 的 名 字 可 以 看 出 ， 这 是 栈 的 风格 ， 后 入 移出 ， 就 是 后 注册 的 清理 函数 会 先 执行 。 





其 中 pthread_cleanup pop 的 用 处 是 ， 删 除 注 册 的 清理 函数 。 如 果 参 数 是 非 0 值 ， 那 么 执行 一 次 ， 再 
删除 清理 函数 。 否 则 的 话 ， 就 直接 删除 清理 函数 。 


























第 三 个 问题 最 关键 ， 何 时 会 触发 注册 的 清理 函数 : 











. 当 线 程 的 主 函 数 是 调用 pthread_exit 返 回 的 ， 清 理 函 数 总 是 会 被 执行 。 








` 当 线程 是 被 其 他 线程 调用 pthread_cancel 取 消 的 ， 清 理 函 数 总 是 会 被 执行 。 





: 当 线 程 的 主 函 数 是 通过 return 返 回 的 ， 并 且 pthread_cleanup pop 的 唯一 参数 execute 是 0 时 ， 清 理 函 数 
会 被 执行 。 






































. 当 线 程 的 主 函 数 是 通过 return 返 回 的 ， 并 且 pthread_cleanup_ pop 的 唯一 参数 execute 是 非 零 值 时 ， 清 





理 函 数 会 执行 一 次 。 


下 面 看 下 示例 代码 : 





#include<stdio.h> 
#include<stdlib.h> 
#include<pthread.h> 
#include<string.h> 
void clean (void* arg) 


{ 
} 


void *thread (void *param) 


{ 





printf ("CLEAN UP:%s\n", (char*)arg); 


int input = (int)param; 
printf ("thread start\n"); 
pthread cleanup push(clean,"first cleanup handler"); 
pthread cleanup push(clean,"second cleanup handler"); 
/*work logic here*/ 
if(input != 0){ 

/*pthreaqd _ exit 退出 ,清理 函数 总 会 被 执行 


Rp 
pthread exit((void*)1); 
} 
pthread cleanup pop (0); 
pthread cleanup pop (0); 
/*return 返回 如 果 上 面 
POP 函数 的 参数 是 


0， 则 不 会 执行 清理 函数 


return ((void *)0); 
int main() 


pthread t tid ;) 

void *res }; 

int ret ， 

ret = pthread create(&tid,NULL,thread, (void*)0); 
if(ret != 0) 

{ 





/*error handle here*/ 
return -1; 
} 
pthread join(tid,g&res); 
printf ("first thread exit,return code is Sd\n", (int)res); 
ret = pthread create(&tid,NULL,thread, (void*)1); 
if(ret != 0) 
{ 





/*error handle here*/ 
return -1 
} 
pthread join(tid,g&res); 
printf("second thread exit,return code is %d\n", (int)res); 
return 0; 





当 线 程 用 return 退 出 ， 并 且 pthread_cleanup_pop 的 参数 是 0 时 ， 那 么 注册 的 


函数 不 被 执行 : 








thread start 

first thread exit,return code is 0 
thread start 

CLEAN UP:second cleanup handler 
CLEAN UP:first cleanup handler 
second thread exit,return code is 1 








如 果 将 上 面 示例 代码 中 的 pthread_cleanup _ pop 的 参数 改 成 1 
数 返 回 ， 还 是 在 线程 的 主 函数 中 调用 return 返 回 ， 都 会 调用 清 到 


， 就 会 发 现 ， 无 论 是 调用 pthread_exit 函 


函数 : 





thread start 

CLEAN UP:second cleanup handler 
CLEAN UP:first cleanup handler 
first thread exit,return code is 0 
thread start 

CLEAN UP:second cleanup handler 
CLEAN UP:first cleanup handler 
second thread exit,return code is 1 














有 了 清理 函数 ， 本 节 开 头 处 提 到 的 例子 就 可 以 改进 为 如 下 








void cleanup (void* mutex) { 
pthread mutex unlock( (pthread mutex t*)mutex); 
} 


void* cancel unsafe(void*) { 
static pthread mutex t mutex = PTHREAD MUTEX INITIALIZER; 
pthread cleanup push(cleanup, &mutex); 


pthread mutex lock(&mutex 
struct timespec ts {3 
nanosleep(&ts, 0); 
pthread mutex unlock(&mutex); 
pthread cleanup pop (0); 


); 
= 017 


return 0; 


在 这 种 情况 下 ， 如 果 线 程 被 取消 ， 清 到 








形式 了 : 


8.2 ”线程 局 部 存储 


errno 变 量 是 线程 局 部 存储 的 典型 案例 。 我 们 可 以 通过 该 案例 来 理解 引入 线程 局 部 存储 的 意义 。 











在 多 线程 引入 之 前 ， 由 于 进程 只 有 一 条 控制 流 《〈 暂 不 考虑 信号 处 理 函 数 ) ， 因 此 当 函 数 调用 出 错 
时 ， 可 以 通过 设置 全 局 的 errno 来 提示 遇 到 的 错误 类 型 。 代 码 如 下 所 示 : 














int f = open (...); 
主 下 直下 过 0) 
printf ("error %d encountered\n", errno); 











但 是 自从 引入 多 线程 之 后 ， 情 况 就 发 生 了 变化 。 如 果 errno 仍 然 是 进程 内 的 全 局 变量 ， 就 会 引起 混 
乱 。 考 虑 如 下 两 个 线程 分 别 执行 如 下 代码 : 








1 
int f = open (...); 
{下 过 0) 
printf ("error %d encountered\n", errno); 线 程 


2 
int s = socket (...); 
if (s < 0) 
printf ("error %d encountered\n", errno); 





当 两 个 线程 同时 执行 这 两 部 分 代码 并 且 几 乎 同时 出 错 的 话 ， 后 一 个 出 错时 设置 的 errno 的 值 会 履 诉 
前 一 个 出 错时 设置 的 errno。 因 此 至 少 有 一 个 输出 的 errno 是 不 对 的 。 





对 于 这 个 问题 ， 一 种 解决 的 方法 是 这 样 的 : 


int local errno 
int f = open(...,&local errno) 
主 £E 《( 玉 < .0) 
printf ("error %d encountered\n", local errno); 











这 种 方法 固然 可 以 做 到 对 多 线程 的 支持 ， 但 是 在 现实 中 不 具备 可 操作 性 。 大 量 的 函数 接口 已 经 存 
在 很 入 ， 改 变 接口 意味 着 不 兼容 历史 代码 。 对 errno 而 言 ， 比 较 好 的 方案 是 既 要 能 应 对 多 线程 ， 又 不 需 
要 改变 既 有 的 接口 。 

















这 时 候 ， 线 程 局 部 存储 就 横 空 出 世 了 。 使 用 线程 局 部 存储 〈Thread Local Storage) 技术 就 能 满足 上 
述 的 需求 。 该 技术 为 每 一 个 线程 都 分 别 维护 一 个 变量 的 副本 ， 尽 管 名 字 相 同 却 分 别 存储 ， 并 行 不 悖 。 























在 Linux 下 有 两 种 方法 可 以 实现 线程 局 部 存储 : 


使 用 NPTL 提 供 的 函数 。 











使 用 编译 器 扩展 的 _ thread 关 键 字 。 





8.2.1 使 用 NPTL 库 函数 实现 线程 局 部 存储 





NTPL 提 供 了 一 个 函数 接口 来 实现 线程 局 部 存储 的 功能 : 





int pthread key_create (Pthreadqd_ key t *key,void (*destructor) (void*)); 


int pthread key delete(pthread key t key); 





int pthread setspecific(pthread key t key, const void *value); 


void *pthread getspecific(pthread key t key); 





其 中 ，pthread key_ create 函数 会 为 线程 局 部 存储 创建 一 个 新 键 ， 并 通过 给 key 赋 值 ， 返 回 给 用 户 使 


用 。 


因为 进程 中 的 所 有 线程 都 可 以 使 用 返回 的 键 ， 所 以 参数 key 应 该 指向 一 个 全 局 变量 。 


参数 destructor 指 向 一 个 自 定义 的 函数 : 





void * qestructor (void *value) 


{ 


/* 多 是 为 了 释放 


Value 指 针 指向 的 资源 





线程 终止 时 ， 如 果 key 关 联 的 值 不 是 NULL， 那 么 NTPI 会 自动 执行 定义 的 destructor 函 数 。 如 果 无 须 
解构 ， 可 以 将 destructor 设 置 为 NULL 。 














这 几 个 接口 比较 临 庚 ， 很 难 从 接口 上 想到 如 何 使 用 线程 局 部 存储 。 下 面 通过 一 个 例子 来 说 明 如 何 





使 用 这 些 接口 。 在 下 面 的 例子 里 ， 程 序 希望 每 





个 线程 将 自己 的 log 输 出 到 各 自 独 立 的 文件 。 








#include 
#include 
#include 
#include 








/* 用 于 为 每 个 线程 保存 文件 指针 的 











TSD 键 值 


<malloc.h> 
<pthread.h> 
<stdio.h> 
<stdlib.nh> 


;根据 键 值 可 以 找到 线程 各 自 的 


Data。 


WA 


static pthread key 七 


void write to thread log(const char *message) 


thread log key; 


FILE* thread 1og=(FILE*)pthread getspecificl(thread log key); 
fprintf (thread log, "$s\n", message); 


} 
void fn close thread log(void *thread 109g) 
{ 


} 
void *thread _ function (void *args) 


{ 


fclose( (FILE *)thread 1og) ; 


char thread log filename[128]; 

FILE *thread log;sprintf (thread log filename, "thread%$ld.1o0g", 
unsigned long)pthread self()); 

thread 1o0g = fopen(thread log filename, "“w"); 

/* 将 文件 指针 保存 在 


thread_ 10g _ key 标识 的 


TSD 中 。 


A 
pthread setspecific(thread log key,thread 10g); 
write to thread log("Thread starting."); 
return NULL; 


int main() 
于 认 书生 光 
pthread t threads[5]; 
/* 创建 一 个 键 值 ， 用 于 将 线程 日 志文 件 指针 保存 在 


TSD 中 。 








* 调 











close_threaqd 1og 以 关闭 这 些 文件 指针 。 


大 
/ 
pthread key create(&thread log key, fn close thread 109g); 
for(i = 0; 1i < 5; ++i) 
pthread create (& (threads[i]), NULL, thread function, NULL); 
for(i = 0; 1 < 5; ++i) 
pthread join(threads[i], NULL); 
return 0; 














上 面 的 程序 首先 调用 pthread_key_create 函 数 来 申请 一 个 槽 位 。 在 NPTL 实 现下 ，pthread_ key _t 是 无 符 
号 整 型 ，pthread key create 调用 成 功 时 会 将 一 个 小 于 1024 的 值 填 入 第 一 个 入 参 指向 的 pthread key t 类 型 
的 变量 中 。 








为 什么 键 值 总 是 要 小 于 1024? 那 是 因为 NPTL 实 现 一 共 提 供 了 1024 个 槽 位 。 








如 图 8-1 所 示 ， 记 录 槽 位 分 配 情况 的 数据 结构 pthread_keys 是 进程 唯一 的 。 对 于 上 面 的 示例 代码 而 
言 ， 第 一 次 调用 pthread key_create 毫 无 疑问 会 领 到 slot 0。 即 thread log key 的 值 为 0， 表 示 占 用 了 0 号 槽 
位 ， 如 图 8-1 所 示 。 











pthread_keys[0] 一 一 > 





占用 标志 
解构 函数 指针 
占用 标志 


解构 函数 指针 
用 标志 
函数 指针 





pthread_keys [1] 一 一 > 


— pthread_keys[1023] 一 > a 
占用 标志 
解构 函数 指 


8-1 pthread keys 与 模 位 分 配 











目前 ， 各 个 线程 还 没有 数据 和 该 key 相 关联 。 接 下 来 线程 函数 通过 调用 pthread_setspecific 函 数 ， 将 
key 分 别 与 各 自 的 线程 数据 关联 起 来 。 





pthread setspecific(thread log key,thread 1og) 





每 个 线程 槽 位 号 0 各 自 指向 了 线程 自己 的 数据 。 从 此 处 开始 分 家 ，key 是 同一 个 key， 但 每 个 线程 指 
向 的 数据 各 不 相同 〈 如 图 8-2 所 示 ) 。 








线程 A 槽 位 0 
指向 的 数据 





线程 B 酚 位 0 
指向 的 数据 






线程 C 覃 位 0 
指向 的 数据 










图 8-2 ”同一 个 key 每 个 线程 指向 各 自 的 数据 


线程 如 果 想 要 使 用 各 自 的 值 怎么 办 ? 拿 这 个 key， 去 找到 与 key 关 联 的 数据 结构 ， 这 是 


pthread_getspecific 函 数 的 职责 所 在 。 





FILE* thread log =(FILE *)pthread getspecific(thread log key); 





因为 线程 知道 key 关 联 的 数据 结构 是 什么 类 型 ， 所 以 可 以 从 key 直 接著 取 到 key 指 向 的 value。 取 到 线 


程 的 特有 数据 之 后 ， 就 可 以 操作 了 。 








由 于 key 属 于 全 局 变量 ， 因 此 取 到 的 线程 特有 数据 value 就 变 成 了 线程 内 部 的 “全 局 变量 ”。 








1024 个 key， 对 于 普通 的 应 用 来 说 足够 了 。 如 果 一 个 多 线程 应 用 确实 需要 很 多 的 线程 特有 数据 ， 那 


么 可 以 将 其 封装 在 一 个 数据 结构 之 内 。 





这 种 方法 ， 人 允许 的 键 值 个 数 有 限 并 不 是 问题 的 关键 ， 问 题 的 关键 是 它 的 接口 太 难 用 了 ， 接 口 设 计 


得 有 点 反 人 类 。 





8.2.2 ”使 用 _thread 关 键 字 实现 线程 局 部 存储 











由 于 8.2.1 节 提供 的 接口 太 难 用 ， 有 人 想到 了 在 编译 器 中 增加 新 功能 ， 文 持 特 定 的 关键 字 _thread， 
隐 式 地 构造 线程 局 部 变量 。 








它 的 使 用 方法 非常 简单 : 





_ thread int val = 0; 








凡是 带 有 _thread 关 键 字 的 变量 ， 每 个 线程 都 会 有 该 变量 的 一 个 拷贝 ， 并 行 不 怪 ， 互 不 干扰 。 该 局 
部 变量 一 直 都 在 ， 直 到 线程 退出 为 止 。 











使 用 线程 局 部 变量 需要 注意 以 下 几 点 : 





-如果 变 量 生命 中 使 用 了 关键 字 static 或 extermm， 那 么 关键 字 _thread 应 该 紧 随 其 后 。 
声明 时 ， 可 以 正常 初始 化 。 


可 以 通过 取 地 址 操作 符 〈&) 获取 到 线程 局 部 变量 的 地 址 。 








同样 的 例子 ， 用 __thread 关 键 字 来 实现 就 自然 多 了 ， 代 码 如 下 : 





#include <malloc.h> 

#include <pthread.h> 

#include <stdio.h> 

#include <stdlipb.h> 

_ thread FILE* thread 1o0g = NULL ; 

void write to thread log(const char *message) 
{ 


fprintf (thread log, "$s\n", message); 


} 
void *thread function(void *args) 
{ 
char thread log filename[128];sprintf (thread log filename, "thread%sld.1og", 
(unsigned long)pthread self()); 
thread log = fopen (thread log filename, "Ww"); 
write to thread log("Thread starting."); 
fclose (thread 1og) ; 
return NULL 
} 
int main() 
{ 
rit: 江 汪 
pthread 七 threads[5]; 
for(i = 0; i < 5; ++i) 
pthread create(& (threads[i]), NULL, thread function, NULL); 
for(i = 0; 1 < 5; ++i) 和 
pthread join(threads[i], NULL); 
return 0; 








线程 局 部 存储 需要 内 核 ，Pthreads 实 现 和 C 编 译 器 提供 了 文 持 。 对 线程 局 部 存储 (Thread Local 
Storage) 的 实现 感 兴趣 的 话 ，Ulrich Drepper 著 有 “ELF Handling For Thread-Local Storage” 一 文 ， 是 非常 
好 的 参考 资料 。 





8.3 ”线程 与 信号 





言 写 出 现 地 要 比 线程 早 ， 所 以 设计 信号 时 ， 尚 没有 线程 。 在 引入 线程 之 后 ， 如 何 设计 信号 成 了 
个 难点 。 既 要 保证 传统 的 语义 不 变 ， 又 要 设计 出 适用 于 多 线程 环境 的 信号 模型 ， 确 实 难 度 不 小 。 


























在 第 6 章 “ 信 号 "一 章 中 ， 已 基本 讲 清 楚 了 多 线程 和 信和 号 的 关系 ， 以 及 内 核 如 何 实现 。 在 此 ， 仅 仅 总 






































信号 处 理 函 数 是 进程 层面 的 概念 ， 或 者 说 是 线程 组 层面 的 概念 ， 线 程 组 内 所 有 线程 共享 对 信和 号 的 
处 理 函 数 。 









































.对 于 发 送 给 进程 的 信号 ， 内 核 会 任 选 一 个 线程 来 执行 信号 处 理 函 数 ， 执 行 完 后 ， 会 将 其 从 挂 起 信 
号 队列 中 去 除 ， 其 他 进程 不 会 对 一 个 信和 号 重复 啊 应 。 














可 以 针对 进程 中 的 茶 个 线程 发 送信 号 ， 那 么 只 有 该 线程 能 啊 应 ， 执 行 相应 的 信号 处 理 函 数 。 


























信号 掩 码 是 线程 层面 的 概念 ， 信 和 号 处 理 函 数 在 线程 组 内 是 统一 的 ， 但 是 信号 担 码 是 各 自 独立 可 配 
置 的 ， 各 个 线程 独立 配置 自己 要 阻止 或 放行 的 信号 集合 。 




















. 挂 起 信号 〈 内 核 已 经 收 到 ， 但 尚未 递送 给 线程 处 理 的 信号 ) 既是 针对 进程 的 ， 又 是 针对 线程 的 。 
内 核 维护 两 个 挂 起 信号 队列 ， 一 个 是 进程 共享 的 挂 起 信号 队列 ， 一 个 是 线程 特有 的 挂 起 信号 队列 。 调 
用 函数 sigpending 返 回 的 是 两 者 的 并 集 。 对 于 线程 而 言 ， 优 先 递 送 发 给 线程 自身 的 信和 号。 























上 面 这 些 内 容 ， 基 本 概括 了 多 线程 条 件 下 信号 的 模型 。 内 核 如 何 做 到 这 些 模型 ， 在 第 6 章 中 基本 都 
有 介绍 ， 在 此 处 就 不 再 赣 述 了 。 





8.3.1 设置 线程 的 信号 掩 码 








前 面 已 提 到 过 ， 信 号 掩 码 是 针对 线程 的 ， 每 个 线程 都 可 以 自行 设置 自己 的 信和 号 掩 码 。 如 有 果 自 己 不 
设置 ， 就 会 继承 创建 者 的 信号 掩 码 。 





NPTL 实 现 了 如 下 接口 来 设置 线程 的 信号 撼 码 : 





#include <signal.h> 
int pthread sigmask (int how, const sigset t *new, sigset t *old); 





how 的 值 用 来 指定 如 何 更 改 信号 组 : 





SIG_ BLOCK 向 当前 信号 掩 码 中 添加 new， 其 中 new 表 示 要 阻塞 的 信号 组 。 











SIG _ UNBLOCK 从 当前 信号 掩 码 中 删除 ew， 其 中 new 表 示 要 取消 阻塞 的 信号 组 。 


“SIG_SETMASK 将 当前 信号 掩 码 蔡 换 为 ew， 其 中 new 表 示 新 的 信号 掩 码 。 








该 接口 的 使 用 方式 和 sigprocmask 一 模 一 样 ， 在 Linux 上 ， 两 个 函数 的 实现 是 相同 的 。 





四 

说 明 ”SIGCANCEL 和 SIGSETXID 信 号 被 用 于 NPTL 实 现 ， 因 此 用 户 不 能 也 不 应 该 改变 这 两 
个 信号 的 行为 方式 。 好 在 用 户 不 用 操心 这 两 个 信号 ，sigprocmask 函 数 和 pthread _ sigmask 函 数 对 这 两 者 都 
做 了 特殊 处 理 。 














8.3.2” 回 线 程 发 送信 和 号 








第 6 章 提 到 过 向 线程 发 送信 和 号 的 系统 调用 tkilytekill， 无 奈 glibc 并 未 将 它们 封装 成 可 以 直接 调用 的 函 
数 。 不 过 ， 幸 好 提供 了 另外 一 个 函数 : 





int pthread kill (Pthread t thread, int sig); 





由 于 pthread_t 类 型 的 线程 ID 只 在 线程 组 内 是 唯一 的 ， 其 他 进程 完全 可 能 存在 线程 ID 相同 的 线程 ， 所 
以 pthread_kill 只 能 向 同一 个 进程 的 线程 发 送信 号 。 


除了 这 个 接口 外 ，Linux 还 提供 了 特有 的 函数 将 pthread_kill 和 sigqueue 功 能 累加 在 一 起 : 





#define GNU SOURCE 

#include <pthread.h> 

int pthread sigqueue (pthread t thread, int sig, 
const union sigval value); 








这 个 接口 和 sigqueue 一 样 ， 可 以 发 送 携带 数据 的 信号 。 当 然 ， 只 能 发 给 同一 个 进程 内 的 线程 。 








8.3.3 ”多 线程 程序 对 信和 号 的 处 理 
单线 程 的 程序 ， 对 信和 号 的 处 理 已 经 比较 复杂 了 。 因 为 信号 打 断 了 进程 的 控制 流 ， 所 以 信和 号 处 理 函 
全 是 个 很 苛刻 的 条 件 。 


呈 ， 也 可 以 发 送 给 进程 内 的 茶 一 


Ey 




















异步 信号 安全 的 函数 。 而 异步 信号 安 








i 
2 


数 只 能 


线 














多 线程 的 引入 ， 加 剧 了 这 种 复杂 度 。 因 为 信号 可 以 发 送 给 进 丰 
程 。 不 同 线程 还 可 以 设置 自己 的 掩 码 来 实现 对 信号 的 屏蔽 。 而 且 ， 没 有 一 个 线程 相关 的 函数 是 异步 信 
言 号 处 理 函 数 不 能 调用 任何 pthread 函 数 ， 也 不 能 通过 条 件 变量 来 通知 其 他 线程 。 











号 安全 的 ， 
正如 陈 硕 在 《Linux 多 线程 服务 器 编程 》 中 提 到 的 ， 在 多 线程 程序 中 ， 使 用 信号 的 第 一 原则 就 是 不 

















要 使 用 信号 。 
不 要 主动 使 用 信号 作为 进程 间 通 信 的 手段 ， 收 益 和 引入 的 风险 完全 不 成 比例 。 
能 是 例外 ， 默 认 语义 是 


月 征 




















日 于 管道 和 socket 的 SIGPIPE 可 








不 主动 改变 异常 处 理 信 号 的 信号 处 理 函 数 。 月 
终止 进程 ， 很 多 情况 下 ， 需 要 忽略 该 信号 。 
那么 就 采 上 











有 sigwaitinfo 或 signal 亿 的 方式 同步 处 理 信和 号， 减少 异 











.如 果 无 法 避免 ， 必 须要 处 理 信和 号， 
步 处 理 带 来 的 风险 和 引入 bug 的 可 能 。 


ZJ 


曾经 分 析 了 如 何 使 用 sigwaitinfo 函 数 和 signal 锯 同步 地 处 理 信 号 ， 此 处 就 不 再 歼 述 了 。 


在 第 6 章 中 ， 








8.4 多 线程 与 fork () 


多 线程 和 fork 函 数 的 协作 性 非常 差 。 对 于 多 线程 和 fork， 最 
里 面 调 用 fork。 





HI 


要 的 建议 就 是 永远 不 要 在 多 线程 程序 














请 跟 我 再 念 一 过 永远 不 要 在 多 线程 程序 里 面 调用 fork。 























Linux 的 fork 函 数 ， 会 复制 一 个 进程 ， 对 于 多 线程 程序 而 言 ，fork 函 数 复 制 的 是 调用 fork 的 那个 线 
程 ， 而 并 不 复制 其 他 的 线程 。fork 之 后 其 他 线程 都 不 见 了 。Linux 不 存在 forkall 语 义 的 系统 调用 ， 无 法 做 
到 将 多 线程 全 部 复制 。 























多 线程 程序 在 fork 之 前 ， 其 他 线程 可 能 正 持 有 互 斥 量 处 理 临界 区 的 代码 。fork 之 后 ， 其 他 线程 都 不 
见 了 ， 那 么 互 斥 量 的 值 可 能 处 于 不 可 用 的 状态 ， 也 不 会 有 其 他 线程 来 将 互 斥 量 解锁 。 














下 面 用 一 个 例子 来 描述 这 种 场景 : 








#include <stdio.h> 
#include <signal.h> 
#include <stdlib.h> 
#include <unistd.h> 
#include <pthread.h> 
#include <sys/wait.h> 
static void* worker (void* arg) 
{ 
pthread detach (pthread self()); 
FG (es 
{ 
setenv ("foo", "bar", 1); 
usleep (100); 
} 
return NULL; 
} 
static void sigalrm(int sig) 
{ 
chare Tl = a 
write (filenol(stderr), &a, 1); 


int main() 
{ 
pthread t setenv thread; 
pthread create(&setenv thread, NULL, worker, 0); 
for (;;) 
{ 
pid t pid = fork(); 
if (pid == 0) 
{ 
signal (SIGALRM, sigalrm); 
alarm(1); 
unsetenv ("bar"); 
exit (0); 
} 
wait3 (NULL, WNOHANG, NULL); 
usleep (2500); 
} 


return 0; 





上 面 的 代码 比较 简单 ， 创 建 了 一 个 线程 周期 性 地 执行 Setenv 函 数 ， 修 改 环 境 变 量 。 主 线程 会 fork 子 
进程 ， 子 进程 负责 执行 unsetenv 函 数 ， 同 时 调用 了 alarm， 一 秒 钟 后 会 收 到 SIGALRM 信 号 。 子 进程 通过 
执行 signal 函 数 ， 注 册 了 SIGALRM 信 和 号 的 处 理 函 数 ， 即 回 标 准 错误 打印 字母 a"。 





fork 创 建 的 子 进程 在 调用 alarm 注 册 的 闹钟 之 后 ， 只 执行 unsetenv 函 数 ， 然 后 就 会 调用 exit 民 出 。 

















此 ， 在 正常 情况 下 子 进程 很 快 就 会 退出 ，alarm 约 定 的 1 秒 钟 时 间 还 未 到 就 退出 了 。 也 就 是 说 ， 信 号 处 理 
函数 不 应 该 被 执行 ， 自 然 也 就 不 应 该 打印 出 字母 ‘a’。 

















可 是 实际 情况 是 : 





./thread fork 
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa^C 











原因 何在 ? 在 某 些 情况 下 ， 子 进程 为 什么 不 能 及 时 退出 ， 以 至 于 过 了 1 秒 之 后 ， 子 进程 还 没有 退 








出 ? 
选择 一 个 阻塞 的 线程 ， 用 gdb 调 斌 下， 看 看 到 底 阻 塞 在 何 处 。 


(gqb) bt 

#0 111 lock wait private () at ../nptl/sysdeps/unix/sysv/linux/x86 64/lowlevellock.S:95 
#1 Ox00007fd5c50270f£6 in LL lock 740 () from /lib/x86 64-linux-gnu/libc.so.6 

#2 Ox00007fd5c5026f2a in ”unsetenv (name=0x400b24 "bar") at setenv.c:325 

#3 0x0000000000400a6d in main () at fork.c:41 





可 以 看 出 调用 unsetenv 的 时 候 ， 子 进程 就 被 卡 住 了 。 
为 什么 ? 


现在 的 库 函 数 ， 为 了 做 到 可 重 入 ， 其 内 部 维护 的 变量 通常 
般 是 透明 的 ， 用 户 也 不 关心 。setenv 和 unsetenv 就 是 这 样 。 尺 
内 部 已 经 维护 了 一 个 互 斥 量 。 


会 使 用 互 斥 量 来 保护 。 这 些 锁 对 用 户 一 
上 述 代 码 并 没有 显 式 地 定义 ， 但 是 进程 














As 
上 














互 斥 量 中 维护 了 一 个 锁 的 值 : 0 表示 未 上 锁 ，1 表 示 已 上 锁 但 是 没有 等 待 线程 ，2 表 示 已 上 锁 ， 并 且 
有 线程 等 待 该 锁 。 对 于 我 们 的 例子 而 言 ， 由 于 线程 每 100 微 秒 就 执行 一 次 setenv， 很 有 可 能 在 主线 程 调 
用 fork 创 建 子 进程 的 瞬间 ， 互 斥 量 的 值 是 1。 而 这 个 值 1 被 揽 贝 到 了 子 进程 。 
























































对 于 父 进程 而 言 互 斥 量 的 值 是 1 自然 没有 关系 ， 因 为 父 进程 中 有 线程 worker 不 停 地 加 锁 、 解 锁 。 但 
是 子 进程 的 情况 就 不 同 了 ， 子 进程 中 没有 worker。 子 进程 自 创 建成 功 开 始 ，setenv 相 关 的 互 斥 量 的 值 就 
一 直 是 1。 子 进程 调用 unsetenv 函 数 时 , “地 雷 ” 被 引爆 了 。unsetenv 无 法 获得 互 斥 量 ， 反 而 是 通过 调用 
futex 系 统 调 用 陷入 休眠 ， 内 核 将 其 挂 入 对 应 的 等 待 队列 。 



































父 进 程 的 worker 线 程 的 解锁 操作 会 唤醒 子 进程 吗 ? 





下 面 是 内 核 get_ ftex key 函 数 中 的 部 分 代码 : 


if (!fshared) { 
if (unilikely(!access ok(VERIFY WRITE, uaddr, sizeof (u32)))) 


return -EFAULT; 
key->private.mm = mm; 
key->private.address = address; 
get futex key refs (key); 
return 0; 














新 建立 的 futex 使 用 mm 结构 指针 和 地 址 address 作 为 futex 的 键 值 ， 由 于 父子 进程 之 间 并 不 共享 
mm_struct， 也 就 是 说 子 进程 的 fatex 和 父 进程 fatex 并 不 共享 等 待 队列 。 换 名 话说 ， 父 进程 通过 setenv 解 锁 
时 ， 根 本 就 不 会 唤醒 子 进程 。 因 此 ， 子 进程 永远 都 不 可 能 被 唤醒 了 。 















































这 仅仅 是 setenvunseteny 函 数 ， 库 函数 中 类 似 这 种 的 函数 并 不 少见 : 





malloc 函 数 的 内 部 实现 一 定 会 有 锁 。 





:printf 系 列 的 函数 ， 其 他 线程 可 能 持 有 stdout/stderr 的 锁 。 


`Syslog 函 数 内 部 实现 也 会 用 到 锁 。 








综合 上 面 的 讨论 ， 唯 一 安全 的 做 法 是 ，fork 之 后 子 进程 立即 调用 exec 执 行 另外 的 程序 ， 彻 底 断 绝 子 
进程 与 父 进程 之 间 的 关系 ， 注 意 是 立即 ， 不 


和 ， 不 要 在 调用 exec 之 前 执行 任何 语句 ， 哪 怕 是 不 起 眼 的 printf。 








第 9 章 ”进程 间 通 信 : 管道 





在 Linux 系 统 中 ， 有 了 时候 需 要 多 个 进程 相互 协作 ， 共 同 完 成 菜 项 任务 。 进 程 之 间或 线程 之 间 有 时 候 
需要 传递 消息 ， 有 时 候 需 要 同步 来 协调 彼此 的 工作 。 接 下 来 的 3 章 将 讲述 Linux 中 的 进程 间 通 信 


(interprocess communication， 或 者 IPC) 。 




















在 第 6 章 讲 信号 时 曾 提 到 ， 信 和 号 也 是 进程 间 通 信 的 一 种 机 制 ， 尽 管 其 主要 作用 不 是 这 个 。 一 个 进程 
向 男 外 一 个 进程 发 送信 和 号， 传递 的 信息 是 信号 编号 。 当 采用 sigqueue 函 数 发 送信 号 时 ， 还 可 以 在 信 
绑 定 数据 《〈 整 型 数字 或 指针 ) ， 增 强 传递 消息 的 能 力 。 尽 管 如 此 ， 还 是 不 建议 将 信号 作为 进程 间 通 信 
的 常规 手段 ， 原 因 在 信号 那 一 章 中 已 经 详细 介绍 过 了 。 
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在 第 7 章 讲 线程 时 曾 提 到 ， 线 程 在 Linux 中 被 实现 为 轻 量 级 的 进程 ， 线 程 之 间 的 同步 手段 〈 互 斥 量 和 
条 件 等 待 ) ， 本 质 上 也 是 进程 间 通 信 。 














进程 间 通 信 的 手段 ， 大 体 可 以 分 成 以 下 两 类 : 


第 一 类 是 通信 类 。 这 类 手段 的 作用 是 在 进程 之 间 传 递 消 息 ， 交 换 数据 。 若 细 分 下 来 ， 通 信 类 也 可 
以 分 成 两 种 ， 一 种 是 用 来 传递 消息 的 (比如 消息 队列 ) ， 另 外 一 种 是 通过 共享 一 片 内 存 区 域 来 完成 信 
息 的 交换 的 (比如 共享 内 存 ) ， 如 图 9-1 所 示 。 








第 二 类 是 同步 类 。 这 类 手段 的 目的 是 协调 进程 间 的 操作 。 茶 些 操作 ， 多 个 进程 不 能 同时 执行 ， 否 
则 可 能 会 产生 错误 的 结果 ， 这 就 需要 同步 类 的 工具 来 协调 。 主 要 的 同步 类 手段 如 图 9-2 所 示 。 




















从 历史 的 角度 来 说 ，Linux 下 进程 间 通 信 的 手段 基本 上 是 从 Unix 平 台 继 承 而 来 的 。 





管道 是 第 一 个 广泛 应 用 的 进程 间 通 信 手 段 。 日 常 在 终端 执行 shell 命 令 时 ， 会 大 量 用 到 管道 。 但 管 
道 的 缺陷 在 于 只 能 在 有 亲缘 关系 (有 共同 的 祖先 ) 的 进程 之 间 使 用 。 为 了 突破 这 个 限制 ， 后 来 引入 了 
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图 9-2 ”同步 类 工具 


接 下 来 AT&T 的 贝尔 实验 室 和 加 州 大 学 伯克利 分 校 的 伯克利 软件 发 布 中 心 (BSD) 分 别 开 发 出 了 风 
格 迎 异 的 进程 间 通 信 手 段 。 前 者 通过 对 早期 的 进程 间 通 信 手 段 的 改进 和 扩充 ， 开 发 出 System VIPC， 包 
括 消息 队列 、 信 号 量 和 共享 内 存 。 但 是 这 些 方法 ， 将 进程 间 的 通信 始终 局 限 在 单个 计算 机 这 个 范围 之 


























内 。BSD 则 走 了 一 条 完全 不 同 的 道路 ， 开 发 出 了 套 接 字 (socket) ， 跳 











上 了 单机 的 限制 ， 可 以 实现 不 同 











计算 机 之 间 的 进程 间 通 信 。Linux 将 System V IPC 和 BSD socket 都 继承 了 下 来 ， 丰 富 了 进程 间 通 信 的 方 





;去 。 


System VIPC 方 法 出 现 地 比较 早 ， 几 乎 所 有 的 Unix 平 台 都 支持 System VIPC， 其 可 移植 性 较 好 ， 但 是 
在 使 用 过 程 中 也 暴露 出 一 些 弱 点 。POSIX IPC 提 供 了 和 System V 了 PC 相对 应 的 工具 《〈 它 也 包括 消息 队 








列 、 信 号 量 和 共享 内 存 )， 它 的 出 现 晚 于 System V IPC。System V IPC 广 














泛 应 用 了 一 段 时 间 后 ， 才 开始 


设计 POSIX IPC 的 ， 因 此 ， 设 计 者 可 以 借鉴 System V IPC 的 长 处 ， 避 免 其 缺点 。 从 设计 的 角度 上 
讲 ，POSIX 耻 C 是 优 于 System V IPC 的 ， 接 口 简单 ， 易 于 使 用 。 但 是 POSIX PC 的 可 移植 性 并 不 如 System 





VIPC。 














下 面 将 分 别 介绍 进程 间 通 信 的 工具 。 其 中 的 套 接 字 在 后 面 会 有 专门 








的 章节 来 介绍 ， 就 不 在 进程 间 











通信 部 分 提 及 了 。 考 虑 到 进程 间 通 信 的 内 容 比较 多 ， 所 以 一 共 分 成 三 章 依 次 介绍 ， 本 章 将 主要 介绍 管 
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9.1 管道 


9.1.1 管道 概述 





是 最 早出 现 的 进程 间 通 信 的 手段 。 在 shell 中 执行 命令 ， 经 常会 将 上 一 个 命令 的 输出 作为 下 一 个 命 
令 的 输入 ， 由 多 个 命令 配合 完成 一 件 事情 。 而 这 就 是 通过 管道 来 实现 的 。 














在 图 9-3 中 ， 进 程 who 的 标准 输出 ， 通 过 管道 传递 给 下 游 的 we 进程 作为 标准 输入 ， 从 而 通过 相互 配合 
成 了 一 件 任务 。 








who 进程 wc -1 进程 
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人 进程 
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图 9-3 ”管道 的 示意 图 











能 用 于 父子 进程 之 间 ， 也 可 以 用 在 兄弟 进程 之 间 ， 还 可 以 用 于 祖 孙 进程 之 间 甚 至 是 叔 侄 进 程 之 
间 。 总 而 言 之 ， 只 要 共同 的 祖先 曾经 调用 了 pipe 函 数 ， 打 开 的 管道 文件 就 会 在 fork 之 后 ， 被 各 个 后 代 进 程 所 
共享 。 打 开 的 管道 文件 ， 就 像 是 创建 了 一 个 家 族 私密 场所 ， 由 远 祖 进程 来 创建 ， 家 族 所 有 成 员 都 知晓 。 家 
族 成 员 可 以 将 消息 存放 进 该 私密 场所 ， 等 待 男 外 一 个 接头 的 家 族 成 员 来 取 走 消息 ， 阅 后 即 焚 。 





道 的 作用 是 在 有 亲缘 关系 的 进程 之 间 传 递 消 息 。 所 谓 有 亲缘 关系 ， 是 指 有 一 个 共同 的 祖先 。 所 以 管 
内 各 









































严格 来 说 ， 家 族 里 面 的 多 个 进程 都 可 以 往 同一 个 秘密 场所 里 面 扔 消息 ， 也 可 以 都 从 同一 个 秘密 场所 里 
面 取消 息 ， 但 是 真 的 这 么 做 的 话 又 会 存在 风险 。 管 道 实质 是 一 个 字 节 流 ， 并 非 前 面 提 到 的 消息 ， 没 有 消息 
的 边界 。 如 果 多 个 进程 发 送 的 字 节 流 混 在 一 起 ， 则 无 法 辨认 出 各 自 的 内 容 。 所 以 一 般 是 两 个 有 杀 缘 关系 的 
进程 用 管道 来 通信 。 从 程序 设计 的 角度 来 讲 ， 当 进程 调用 pipe 函 数 时 ， 哪 两 个 有 亲缘 关系 的 进程 使 用 该 管 
道 来 通信 应 是 事先 约定 好 的 ， 其 他 有 亲缘 关系 的 进程 不 应 该 进来 搅局 。 其 他 进程 想 通 信 怎么 办 ? 那 就 创建 
它们 之 间 需 要 用 的 另外 的 管道 












































前 面 曾 提 到 过 ， 管 道中 的 内 容 是 阅 后 即 焚 的 ， 这 个 特性 指 的 是 读 取 管 道内 容 是 消耗 型 的 行为 ， 即 一 个 
进程 读 取 了 管道 内 的 一 些 内 容 之 后 ， 这 些 内 容 就 不 会 继续 在 管道 之 中 了 。 一 般 来 讲 管道 是 单 癌 的 。 

















道里 面 写 内 容 ， 另 外 一 个 进程 读 取 管 道里 的 内 容 。 若 两 个 有 杀 缘 关系 的 进程 发 扬 二 杆子 精神 ， 
入 管道 里 面 读 ， 上 自然 也 是 可 以 的 ， 但 是 管道 中 的 内 容 可 能 会 变 得 混乱 ， 从 而 无 法 
完成 通信 的 任务 。 如 果 两 个 进程 之 间 想 双向 通信 怎么 办 ? 可 以 建立 两 个 管道 ， 如 图 9-4 所 示 。 
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图 9-4 ”利用 两 个 管道 双 辐 通 信 

















管道 是 一 种 文件 ， 可 以 调用 read、write 和 close 等 操作 文件 的 接口 来 操作 管道 。 另 一 方面 管道 又 不 是 一 
种 普通 的 文件 ， 它 属于 一 种 独特 的 文件 系统 : pipefs。 管 道 的 本 质 是 内 核 维护 了 一 块 缓冲 区 与 管道 文件 相关 
联 ， 对 管道 文件 的 操作 ， 被 内 核 转换 成 对 这 块 缓冲 区 内 存 的 操作 。 下 面 我 们 来 看 一 下 如 何 使 用 管道 。 





























在 Linux 下 ， 可 以 使 














如 下 接 
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#include <unistd.h> 
int pipe(int pipefd 


D 











如 果 成 功 ， 则 返 


瑟 
















































































值 是 9，， 如 果 失 败 ， 则 返 







































































并 且 设 置 errno。 





处 理 的 errno 如 表 9-1 所 示 。 







































































































































































































































































































































































































































































表 9-1 pipe 函数 的 出 错 情况 
errno 原 
EMFILE 该 进程 使 用 的 文件 描述 符 已 经 多 于 MAX_OPEN-2 
ENFILE 系统 中 同时 打开 的 文件 已 经 超过 了 系统 的 限制 
EFAULT pipefd 参数 不 合法 
成 功 调用 pipe 函 数 之 后 ， 会 返回 两 个 打开 的 文件 描述 符 ， 一 个 是 管道 的 读 取 端 描述 符 pipefa[0]， 另 一 个 是 管道 的 写 入 端 描述 符 pipefd[1]。 管 
道 没 有 文件 名 与 之 关联 ， 因 此 程序 没有 选择 ， 只 能 通过 文件 描述 符 来 访问 管道 ， 只 有 那些 能 看 到 这 两 个 文件 描述 符 的 进程 才能 够 使 用 管道 。 那 
么 谁 能 看 到 进程 打开 的 文件 描述 符 呢 ? 只 有 该 进程 及 该 进程 的 子孙 进程 才能 看 到 。 这 就 限制 了 管道 的 使 用 范围 。 
成 功 调用 pipe 函 数 之 后 ， 可 以 对 写 入 端 描述 符 pipefd[1] 调 用 write， 向 管道 里 面 写 入 数据 ， 代 码 如 下 所 示 : 
write (Pipefd[1],wbuf,count)， 
旦 向 管道 的 写 入 端 写 入 数据 后 ， 就 可 以 对 读 取 端 描 述 符 pipefd[0] 调 用 read， 读 出 管道 里 面 的 内 容 。 如 下 所 示 ， 管 道上 的 read 调 用 返回 的 字 
节 数 等 于 请 求 字 节 数 和 管道 中 当前 存在 的 字 节 数 的 最 小 值 。 如 果 当 前 管道 为 空 ， 那 么 read 调 用 会 阻塞 〈 如 果 没 有 设置 O0 NONBLOCK 标 志 位 的 
话 ) 。 
read (pipefd[0],rbuf,count); 
管道 一 端 是 写 入 端 (pipefd[1]) ， 男 一 端 是 读 取 端 (pipefa[0]) 。 不 应 该 对 读 取 端 描述 符 调 用 写 操作 ， 也 不 应 该 对 写 入 端 描述 符 调用 读 操 
作 。 如 果 我 二 杆子 精神 爆发 ， 非 要 向 读 取 端 描述 符 写 入 ， 或 者 读 取 写 入 端 描述 符 ， 结 果 会 怎么 样 ? 
调用 pipe 函 数 返回 的 两 个 文件 描述 符 中 ， 读 取 端 pipefd[0] 文 持 的 文件 操作 定义 在 read_pipefifo fops， 写 入 端 pipefd[1] 支 持 的 文件 操作 定义 在 
write_pipefifo fops， 其 定义 如 下 : 





const struct file operations read pipefifo fops = { 


-llseek = no llseek, 
.read = do_sync reagd, 
.aio read = pipe read, 
.write = bad pipe w, 
.Poll = pipe poll, 


.unlocked ioctl = pipe ioctl, 
= pipe _ read open, 
= pipe _ read release, 
= pipe read fasync, 


.open 
.release 
.fasync 


}; 


Const struct file operations write pipefifo fops = { 


.llseek = no llseek 
.read = bad pipe r, 
.write = do sync write, 
.aio write = pipe write, 
.poll = pipe poll, 


.unlocked ioctl = pipe ioctl, 













































































.open = pipe_write open, 
release 二 Pipe 1 write release, 
.fasync = pipe write fasync, 
}; 
我 们 可 以 看 到 ， 对 读 取 端 描述 符 执行 write 操作 ， 内 核 就 会 执行 pad_pipe_w 函 数 ， 对 写 入 端 描述 符 执行 read 操 作 ， 内 核 就 会 执行 bad_pipe _T 函 
数 。 这 两 个 函数 比较 简单 ， 都 是 直接 返回 -EBADF。 因 此 对 应 的 read 和 write 调用 都 会 失败 ， 返 回 -1， 并 置 errno 为 EBADF。 
static ssize 七 
char _ user *buf, size t count, loff t *ppos) 


bad pipe r(struct file *filp, 
{ 


return -EBADF; 
} 


static ssize 七 


bad pipe wl(struct file *filp, 


return -EBADF; 


const char 


_ user *buf, size t count,1off t *ppos) 
































我 们 只 介绍 了 Pipe 函数 接口 ， 至 今 尚 看 不 出 来 该 如 何 使 ) 























jpipe 函 数 进行 进程 间 通 信 。 调 
































jpipe 之 后 ， 进 程 发 生 了 什么 呢 ? 请 看 图 9-5。 









调用 pipe 函 数 的 进程 






pipefd[1] 


pipefd[0] 























图 9-5 ”进程 调用 pipe 函 数 后 














可 以 看 到 ， 调 用 pipe 函 数 之 后 ， 系 统 给 进程 分 配 了 两 个 文件 描述 符 





























， 即 pipe 函 数 返 回 的 两 个 描述 符 。 该 进程 既 可 以 往 写 入 端 描述 符 写 入 信 
息 ， 也 可 以 从 读 取 端 描述 符 读 出 信息 。 可 是 一 个 进程 管道 ， 起 不 到 任何 通信 的 作用 。 这 不 是 通信 ， 而 是 自 言 自 语 。 





























































































































如 果 调 用 pipe 函 数 的 进程 随后 调用 fork 函 数 ， 
f 示 ) ， 两 条 通信 的 通道 就 建立 起 来 了 。 此 时 ， 可 








创建 了 子 进程 ， 情 况 就 不 一 样 了 。fork 以 后 ， 子 进程 复制 了 父 进 程 打开 的 文件 描述 符 ( 如 图 9-6 


[以 是 父 进 程 往 管 道里 写 ， 子 进程 从 管道 里 面 读 ， 也 可 以 是 子 进 
里 面 读 。 这 两 条 通路 都 是 可 选 的 ， 但 是 不 能 都 选 。 原 因 
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程 往 管道 里 写 ， 父 进程 从 管道 
前 面 介绍 过 ， 管 道里 面 是 字 节 流 ， 父 子 进程 都 号、 都 读 ， 就 会 导致 内 容 混 在 一 起 ， 对 于 
管道 的 一 方 ， 解 析 起 来 就 比较 困难 。 常 规 的 使 用 方法 是 父子 进程 一 方 只 能 写 入 ， 男 一 方 只 能 读 出 ， 管 道 变 成 一 个 单 向 的 通道 ， 以 方便 使 用 。 
[0 图 9-7 所 示 ， 父 进程 放弃 读 ， 子 进程 放弃 写 ， 变 成 父 进程 写 入 ， 子 进程 读 出 ， 成 为 一 个 通信 的 通道 。 
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注 






























































调用 pipe 函 数 的 进程 


pipefd[1] pipefd[0] 





pipefd[1] 


pipefd[1] 



































图 9-7 fork 之 后 ， 各 自 关闭 不 用 的 文件 描述 符 


























父 进程 如 何 放弃 读 ， 子 进程 又 如 何 放弃 写 ? 其 实 很 简单 ， 父 进程 把 读 端 口 pipefd[0] 这 个 文件 描述 符 关闭 掉 ， 子 进程 把 写 端口 pipefd[1] 这 个 文 
件 描述 符 关闭 掉 就 可 以 了 ， 示 例 代码 如 下 : 












































int pipefd[2]; 

pipe (pipefd); 

switch (fork ()) 

{ 

case -1: 

/*fork failed, error handler here*/ 


case 0: /* 子 进程 


wf 
close (pipefd[1]) 


wy 
/* 子 进程 可 以 对 


Pipefqd[0] 调 用 


read*/ 
break: 


default : /* 父 进程 


wy 


close (pipefd[0]); 


*/ 
/* 父 进程 可 以 对 


Pipefqd[1] 调 用 


Write， 写 入 想 告知 子 进程 的 内 容 


? /* 关 闭 掉 写 入 端 对 应 的 文件 描述 符 


/* 父 进程 关闭 掉 读 取 端 对 应 的 文件 描述 符 




















































































































* 
break 
} 
从 内 核 的 角度 看 ， 调 用 pipe 之 后 ， 系 统 给 进程 分 配 了 两 个 文件 描述 符 ， 调 用 fork 之 后 ， 子 进程 也 就 有 了 与 管道 对 应 的 两 个 文件 描述 符 。 和 普 
通 文件 不 同 ， 这 两 个 文件 描述 符 对 应 的 是 一 块 内 存 缓冲 区 域 ， 如 图 9-8 所 示 。 













































































图 9-8 也 讲述 了 如 何在 兄弟 进程 之 间 通 过 管道 亿 
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就 可 以 通过 














子 进程 之 | 









































党 道 通信 了 。 父 进程 为 了 不 干扰 两 个 子 进程 通信 ， 很 自觉 地 关闭 了 自己 的 写 入 端 。 



























































通信 通道 。 在 shell 中 执行 管道 命令 就 是 这 种 情景 ， 只 是 略 


述 符 。 














特殊 之 处 ， 其 特殊 的 地 方 是 管道 描述 符 占 




















信 。 如 图 9-8 所 示 ， 父 进程 再 次 创建 一 个 子 进程 B， 子 进程 B 就 持 有 管道 写 入 端 ， 这 时 候 两 个 
从 此 管道 成 为 了 两 个 子 进程 之 间 的 六 




















3 了 标准 




















输入 和 标准 输出 两 个 文件 





眶 




















父 进程 打开 的 文件 描述 符 子 进程 打开 的 文件 描述 符 


pipefd[0] 
pipefd[1] 












pipefd[0] 
pipefd[1] 





管道 文件 缓冲 区 


父 进程 打开 的 文件 描述 符 子 进程 打开 的 文件 描述 符 
ra 


pipefd[1] 








父 进程 打开 的 文件 描述 符 子 进程 打开 的 文件 描述 符 


Dipetdlgl 
pipefd[1] 


pipefd[0] 
pipefd[1] 

















另 一 子 进程 打开 的 
文件 描述 符 








图 9-8 ”有 亲缘 关系 的 进程 通过 管道 来 通信 









































9.1.3 ”关闭 未 使 用 的 管道 文件 描述 符 











前 面 提 到 过 ， 用 管道 通信 的 两 个 进程 ， 各 持 有 一 个 管道 文件 描述 符 ， 不 相干 的 进程 应 自觉 关闭 挥 
这 些 文件 描述 符 。 这 么 做 不 仅仅 是 为 了 让 数据 的 流向 更 加 清晰 ， 也 不 仅仅 是 为 了 节省 文件 描述 符 ， 更 
重要 的 原因 是 : 关闭 未 使 用 的 管道 文件 描述 符 对 管道 的 正确 使 用 影响 重大 。 




















管道 有 如 下 三 条 性 质 : 








:只 有 当 所 有 的 写 入 端 描述 符 都 已 关闭 ， 且 管道 中 的 数据 都 被 读 出 ， 对 读 取 端 描 述 符 调 用 read 函 数 
才 会 返回 0〈 即 读 到 EOF 标 志 ) 。 

















.如 果 所 有 读 取 端 描 述 符 都 已 关闭 ， 此 时 进程 再 次 往 管道 里 面 写 入 数据 ， 写 操作 会 失败 ，errno 被 设 
置 为 EPIPE， 同 时 内 核 会 向 写 入 进程 发 送 一 个 SIGPIPE 的 信和 号 





当 所 有 的 读 取 端 和 写 入 端 都 关闭 后 ， 管 道 才能 被 销毁 





由 于 管道 具有 这 些 特性 ， 因 此 我 们 要 及 时 关闭 没 用 的 管道 文件 描述 符 ， 下 面 我 们 来 细 细 分 析 这 样 
做 的 原因 。 








1. 关 闭 无 用 的 管道 写 入 端 








从 管道 读 取 数 据 的 进程 ， 须 要 关闭 其 持 有 的 管道 写 入 端 描述 符 。 不 参与 通信 的 其 他 有 亲缘 关系 的 
进程 也 应 该 关闭 管道 写 入 端 描述 符 。 





























管道 也 符合 生产 者 -消费 者 模型 。 写 入 管道 ， 对 应 于 生产 内 容 ; 读 取 管道 ， 对 应 于 消费 内 容 。 当 所 
有 的 生产 者 都 退场 以 后 ， 消 费 者 应 有 办 法 判断 这 种 情况 ， 而 不 是 傻 傻 地 等 待 已 不 复 存在 的 生产 者 继续 
生产 内 容 ， 以 至 于 陷入 永久 的 阻塞 。 

















如 何 判断 ? 














答案 是 通过 文件 结束 标志 EOF。 当 对 管道 读 取 端 调用 read 函 数 返 回 0 时 ， 就 意味 着 所 有 的 生产 者 都 
退场 了 ， 作 为 消费 者 的 读 取 进 程 ， 就 不 需要 再 继续 等 待 新 的 内 容 了 。 








什么 情况 下 对 管道 读 取 端 描述 符 调用 read 会 返回 0 呢 ? 














:所 有 相关 的 进程 都 已 经 关闭 了 管道 的 写 入 端 描述 符 。 





芭 


道 的 中 已 有 内 容 都 被 读 取 完毕 








同时 满足 上 述 条 件 ， 对 管道 读 取 端 调用 read 会 返回 0。 根 据 这 个 消费 者 就 可 以 判断 管道 内 容 的 生产 
者 已 经 不 存在 了 ， 它 也 不 必 傻 傻 等 待 ， 可 以 关闭 读 取 端 描述 符 了 。 


从 上 面 的 讨论 可 以 看 出 ， 如 果 负 责 读 取 的 进程 ， 或 者 与 通信 无 关 的 进程 ， 不 关闭 管道 的 写 入 端 描 

述 符 ， 就 会 有 管道 写 入 端 描述 符 泄漏 。 当 所 有 负责 写 入 的 进程 都 关闭 了 写 入 端 描述 符 后 ， 负 责 读 的 进 

程 调用 read 时 ， 仍 会 阻塞 于 此 如果 没有 设置 O0 NONBLOCK 标 志 位 的 话 ) ， 而 且 永 不 返回 。 这 是 因为 
内 核 维护 的 引用 计数 发 现 还 有 进程 可 以 写 入 管道 ， 因 此 read 函 数 依旧 会 阻塞 。 












































[e] 


这 个 流程 可 以 通过 一 个 例子 来 验证 





#include <unistd.h> 
#include <sys/types.h> 
#include <errno.h> 
#include <stdio.h> 
#include <stdlib.h> 
int main() 
{ 
irit, pipE, fd[2]y 
pid t pid; 
char r buf{[4096]; 
char w buf{[4096]; 
int writenum; 
int rnum; 
memset (r buf,0,sizeof(r buf)); 
if (pipe (Pipe fd)<0) 
{ 
printf("[PARENT] pipe create error\n"); 
return -1; 


if( (pid=fork()) == 0) 


{ 
/* 如 果子 进程 忘记 关闭 管道 写 入 端 ， 那 么 ， 即 使 父 进程 关闭 了 写 入 端 ， 
Whi1e 循 环 也 无 法 跳出 


4 
close (pipe fd[1]); 


while (1) 

{ 
rnum = read (pipe fqd[0],r buf,1000); 
printf("[CHILD ] readnum is %d\n",rnum); 
if(rnum == 0) /*meet EOF*/ 
{ 





printf("[CHILD ] all the writer of pipe are closed. break and exit.\n"); 
break; 
} 
} 
close (pipe fqd[0]); 
exit (0); 


} 
else if (pid>0) 
{ 


close (pipe fq[0]); 

memset (w | buf,0, sizeof (w buf)); 

if( (writenum = write (pipe fd[l],w buf,1024)) == -1) 
printf ("[PARENT] write to pipe error\n"); 

else 





printf("[PARENT] the bytes write to pipe is %d \n", writenum); 


} 

Sleep (15);，; 

printf("[PARENT] I will close the last write end of pipe.\n"); 
close (pipe fqd[1]); 

Sleep (2); 

return 0; 

















在 上 面 的 例子 中 ， 父 子 进程 通过 管道 进行 通信 ， 父 进程 关闭 了 管道 的 读 取 端 ， 子 进程 关闭 了 管道 
的 写 入 端 。 父 进程 写 入 了 1024 字 节 ， 子 进程 则 在 循环 体 中 调用 read， 每 次 尝试 读 取 1000 字 节 。 子 进程 很 
快 就 读 完了 父 进程 生产 的 1024 字 节 。 但 是 父 进程 并 没有 立刻 关闭 管道 的 写 入 端 ， 而 是 睡眠 了 15 秒 后 ， 


























才 关 闭 管道 。 从 子 进程 读 完 父 进程 生产 的 1024 字 节 开 始 ， 到 父 进程 关闭 管道 写 入 端 这 段 接近 15 
秒 的 时 间 内 ， 子 进程 实际 上 是 阻塞 在 read 函 数 上 的 。 当 父 进程 关闭 管道 号 入 端 ， 子 进程 调用 的 read 函 数 
才 得 以 返回 ， 返 回 值 是 0。 子 进程 看 到 返回 值 0 后 ， 意 识 到 硕果 仅 存 的 管道 写 入 端 也 不 复 存 在 了 ， 所 以 











它 没 必要 再 继续 read 了 ， 于 是 子 进程 就 跳出 了 循环 体 。 


示例 代码 的 输出 如 下 ， 与 我 们 上 面 分 析 的 一 样 : 





[PARENT] the bytes write to pipe is 1024 

[CHILD ] readnum is 1000 

[CHILD ] readnum is 24 

[PARENT] I will close the last write end of pipe. 

[CHILD ] readnum is 0 

[CHILD ] all the writer of pipe are closed. break and exit 











父子 进程 配合 地 珠 联 壁 合 ， 但 是 如 果子 进程 忘记 关闭 管道 的 写 入 端 ，〔 删 除 上 面 示例 代码 中 加 粗 
的 一 行 ) 结局 就 大 相 径 隆 了 。 纵 然 父 进程 关闭 了 管道 的 写 入 端 ， 但 是 因为 管道 仍然 存在 一 个 写 入 端 ， 
所 以 子 进程 的 read 函 数 依旧 会 阻塞 ， 无 法 返回 。 这 显然 不 是 我 们 期 待 的 结果 。 

















2. 关 闭 无 用 的 管道 读 取 端 

















如 果 对 管道 的 号 入 端 描 述 符 调用 write 函数 ， 则 会 走 到 内 核 的 pipe_ write 函数 。 在 该 函数 中 可 以 看 到 
如 下 代码 : 











if (!pipe->readers) { 
send sig(SIGPIPE, current, 0); 
ret = -EPIPE; 
goto out; 


} 


当 管 道 的 读 取 端 不 复 存 在 时 ， 内 核 会 向 write 函数 的 调用 进程 发 送 SIGPIPE 信 号 ， 并 且 当 前 的 write 系 
统 调用 失败 ， 错 误 码 为 EPIPE。 











SIGPIPE 信 和 号 默认 情况 下 会 杀 死 一 个 进程 ， 当 然 我 们 也 可 以 捕获 或 忽略 该 信号 。 事 实 上 大 多 数 情况 
下 ， 服 务 器 端的 程序 都 会 将 SIGPIPE 的 信号 处 理 函 数 设置 成 SIG_ IJGN， 忽 略 掉 该 信号 。 这 样 的 话 ，write 
系统 调用 就 会 返回 失败 ，errmo 是 EPIPE， 通 过 返回 值 和 errno， 就 可 以 及 时 获知 所 有 的 读 取 端 都 已 关闭 
了 。 

















当 所 有 的 管道 读 取 端 都 不 复 存 在 时 ， 管 道 的 号 入 操作 就 会 失败 。 为 何 要 如 此 设计 ? 


证 




















因为 管道 的 读 取 端 是 管道 内 容 的 消费 者 ， 管 道 的 写 入 端 是 管道 内 容 的 生产 者 。 当 消费 者 已 经 不 复 
存在 了 ， 生 产 者 自然 没有 继续 生产 的 必要 了 。 对 于 这 个 道理 ， 电 视 剧 《亮剑 》 中 的 山本 一 木 都 很 清 


林 
人 民 : 














没有 了 观众 ， 也 就 没有 了 表演 。 





所 以 不 参与 通信 的 进程 ， 以 及 负责 向 管道 号 入 内 容 的 进程 应 该 及 时 地 关闭 管道 的 读 取 端 描述 符 。 
只 有 这 样 ， 当 通信 双方 中 的 消费 者 关闭 管道 读 取 端 时 ， 管 道内 容 的 生产 者 才能 在 第 一 时 间 获 知 所 有 消 
费 者 都 已 不 存在 了 这 个 事实 。 


个 




















如 果 写 入 管道 的 进程 不 关闭 管道 的 读 取 文件 描述 符 ， 哪 怕 其 他 进程 都 已 经 关闭 了 读 取 端 ， 该 进程 
仍 可 以 向 管道 写 入 数据 ， 但 是 只 有 生产 者 ， 没 有 消费 者 ， 管 道 最 终 会 被 写 满 ， 当 管道 被 写 满 后 ， 后 续 
的 写 入 请 求 就 会 被 阻塞 。 














下 面 通过 实例 来 证 实 : 当 最 后 一 个 读 取 端 关闭 时 ， 向 管道 写 入 会 触发 SIGPIPE 信 号 ， 同 时 write 会 返 
回 失 败 ，errno 为 EPIPE。 





#include <stdio.h> 
#include <unistd.h> 
#include <stdlib.h> 
#include <fcntl.h> 
#include <signal.h> 
#include <string.h> 
#include <errno.h> 
void sighandler (int signo); 
int main (voidgd) 
{ 

int fqds[2]; 

if (signal (SIGPIPE, sighandler) == SIG ERR) 

{ 


fprintf (stderr,"signal error (%s)\n",strerror (errno)); 
exit (EXIT FAILURE); 


} 
if(pipe (fds) == -1) 
{ 
fprintf (stderr,"create pipe failed(%s)\n",strerror (errno)); 


exit (EXIT FAILURE); 
} 


pid 七 Pid; 
pid = fork() 
if (pid == -1) 


{ 
fprintf (stderr,"fork error (%s)\n",strerror (errno)); 
exit (EXIT FAILURE); 

} 

if (pid == 0) 


fprintf(stdout,"I[ICHILD ] I will close the last read end of pipe \n"); 
close (fdqs [0] ) ; // 子 进程 关闭 读 取 端 文件 描述 符 


exit (EXIT SUCCESS) ; 


} 
close (fds [0] );// 父 进程 关闭 读 取 端 文件 描述 符 


Sleep (1);// 确 保 子 读 取 端 关闭 


int ret; 

ret = writel(fds[1],"hello",5); 
if(ret == -1) 

{ 


} 


return 0; 


fprintf (stderr,"[PARENT] write error(%s)\n",strerror (errno)); 


} 
void sighandler (int signo) 
{ 
printf("[PARENT] catch a SIGPIPE signal and signum = %d\n",signo); 





fork 之 后 ， 父 子 进程 都 立刻 关闭 了 读 取 端 ， 这 时 候 ， 管 道 已 经 不 存在 任何 读 取 端 了 。1 秒 钟 之 后 ， 
父 进 程 尝 试 向 管道 写 入 。 此 时 按照 前 面 的 分 析 ， 父 进程 应 该 会 收 到 SIGPIPE 信 号 ，write 返 回 失败 ， 并 且 
errno 为 EBPIPE。 父 进程 为 SIGPIPE 安 装 了 信和 号 处 理 函 数 ， 如 果 收 到 SIGPIPE 信 和 号， 会 有 打印 提示 。 下 面 来 
看 看 程序 的 输出 : 











[CHILD ] I will close the last read end of pipe 
[PARENT] catch a SIGPIPE signal and signum = 13 
[PARENT] write error ( Broken pipe) 














通过 上 面 的 讨论 可 以 看 出 ， 正 常 使 用 管道 的 场景 ， 应 该 只 有 两 个 进程 和 管道 关联 ， 一 个 进程 只 拥 
有 管道 的 写 入 端 ， 另 一 个 进程 只 拥有 管道 的 读 取 端 。 























如 何 检验 管道 是 否 满足 上 面 的 情形 ? 以 如 下 情况 为 例 : 








int pipefd[2 
ret = pipe (pipefd); 
fork () 


管道 是 文件 的 一 种 ， 在 /proc/PID/ 人 /下 可 以 看 到 打开 的 管道 文件 ， 如 下 所 示 : 








manu@manu-rush:~$ 11 /proc/2889/fd 

total 0 

dr-x-—-—-—--- 2 manu manu 0 Jul 24 00:13 ./ 
dr-xr-xr-x 9 manu manu 0 Jul 24 00:13 ../ 


lrwx-—---- 1 manu manu 64 Jul 24 00:13 0 -> /dev/pts/0 
FTWX- 一 -一 一 一 1 manu manu 64 Jul 24 00:13 1 -> /dev/pts/0 
FTWX- 一 -一 一 一 1 manu manu 64 Jul 24 00:13 2 -> /dev/pts/0 
HI ep 0 1 manu manu 64 Jul 24 00:13 3 -> pipe: [13870] 
3 ps el 1 manu manu 64 Jul 24 00:13 4 -> pipe: [13870] 














可 以 看 出 文件 描述 符 3 和 4 都 是 管道 文件 ， 其 后 面 的 相同 数字 13870 表 示 它 们 属于 同一 个 管道 。 文 件 
描述 符 3 对 应 的 文件 属性 中 有 r， 表 示 管 道 的 读 取 端 ， 文 件 描述 符 4 对 应 的 文件 属性 中 有 w 表 示 4 是 管道 的 
写 入 端 。 



































有 哪些 进程 持 有 管道 对 应 的 文件 描述 符 ? 





| 




















manulmanu-rush:~$ lsof | grep FIFO | grep 13870 


pipe 2889 manu 3r FIFO 0,8 0t0O 13870 pipe 
pipe 2889 manu 4w FIFO 0,8 0t0O 13870 pipe 
pipe 2890 manu 3 FIFO 0,8 0t0 13870 pipe 
pipe 2890 manu 4w FIFO 0,8 0t0O 13870 pipe 


从 上 面 的 输出 可 以 知晓 ， 管 道 13870 并 不 满足 前 面 的 讨论 。 在 理想 情况 下 ， 输 出 应 该 只 有 两 行 ， 一 
个 进程 只 有 管道 的 写 入 端 ， 另 一 个 进程 只 有 管道 的 读 取 端 。 














9.1.4 


A 
此 





管道 对 应 的 内 存 区 大 小 


道 本 质 是 一 片 内 存 区 域 ， 自 然 有 大 小 。 自 Linux 2.6.11 版 本 起 ， 管 道 的 默认 大 小 是 65536 字 节 ， 可 





以 调用 fcntl 来 获取 和 修改 这 个 值 的 大 小 ， 代 码 如 下 : 





获取 管道 的 大 小 


pipe capacity = fcntl (fd,?F GETPIPE SZ) ?设置 管道 的 大 小 


ret = fontl(fd,?F SETPIPE SZ, Size)’; 








己 


ES 


道内 存 区 域 的 大 小 必须 在 页 面 大 小 (PAGE) 和 上 限 值 之 间 ， 其 上 限 记 录 在 /proc/sys/fs/pipe-max- 
size 里 ， 对 于 特权 用 户 ， 还 可 以 修改 该 上 限 值 。 











cat /proc/sys/fs/pipe-max-size 
1048576 





a 
已 
Fi 








管道 








道 的 容量 可 以 扩大 ， 自 然 也 可 以 缩小 。 缩 小 管道 容量 时 会 遇 到 一 种 比较 有 意思 的 场景 ， 即 当前 


管道 中 已 存在 的 内 容 大 于 fentl 函 数 调用 中 指定 的 size， 此 时 fcnt 函 数 会 返回 失败 ， 并 置 错误 码 为 
EBUSY 。 














己 
i 





道 容量 有 大 小 这 个 事实 对 于 编程 有 什么 影响 呢 ? 





在 使 用 管道 的 过 程 中 要 意识 到 : 管道 有 大 小 ， 写 入 须 谨慎 ， 不 能 连续 地 写 入 大 量 的 内 容 ， 一 旦 管 


道 满 了 ， 








写 入 就 会 被 阻塞 ， 对 于 读 取 端 ， 要 及 时 地 读 取 ， 防 止 管 道 被 写 满 ， 造 成 写 入 阻塞 。 


9.1.$ _ shell 管道 的 实现 





shel 编程 会 大 量 使 用 管道 ， 我 们 经 常 看 到 前 一 个 命令 的 标准 输出 作为 后 一 个 命令 的 标准 输入 ， 来 
协作 完成 任务 ， 如 图 9-9 所 示 。 管 道 是 如 何 做 到 的 呢 ? 





兄弟 进程 可 以 通过 管道 来 传递 消息 ， 这 并 不 稀奇 ， 前 面 已 经 图 示 了 做 法 。 关 键 是 如 何 使 得 一 个 程 
序 的 标准 输出 被 重 定向 到 管道 中 ， 而 男 一 个 程序 的 标准 输入 从 管道 中 读 取 呢 ? 














图 9-9 ”管道 在 shell 中 的 应 用 





答案 就 是 复制 文件 描述 符 。 











对 于 第 一 个 子 进 程 ， 执 行 dup2 之 后 ， 标 准 输出 对 应 的 文件 描述 符 1， 也 成 为 了 管道 的 写 入 端 。 这 时 
候 ， 管 道 就 有 了 两 个 写 入 端 ， 按 照 前 面 的 建议 ， 需 要 关闭 不 相干 的 写 入 端 ， 使 读 取 端 可 以 顺利 地 读 到 
EOF， 所 以 应 将 刚 开 始 分 配 的 管道 写 入 端的 文件 描述 符 pipefd[1] 关 闭 掉 。 








if (pipefd[1] != STDOUT FILENO) 


dup2 (pipefd[1],STDOUT FILENO); 
close (pipefd[1]); 
} 





同样 的 道理 ， 对 于 第 二 个 子 进程 ， 如 法 炮制 ; 





if (pipefd[0] != STDIN FILENO) 


dup2 (pipefd[0],STDIN FILENO); 
close (pipefd[0]); 
} 








简单 来 说 ， 就 是 第 一 个 子 进 程 的 标准 输出 被 绑 定 到 了 管道 的 号 入 端 ， 于 是 第 一 个 命令 的 输出 ， 号 
入 了 管道 ， 而 第 二 个 子 进程 管道 将 其 标准 输入 绑 定 到 管道 的 读 取 端 ， 只 要 管道 里 面 有 了 内 容 ， 这 些 内 











容 就 成 了 标准 输入 。 


两 个 示例 代码 ， 为 什么 要 判断 管道 的 文件 描述 符 是 否 等 于 标准 输入 和 标准 输出 呢 ? 原因 是 ， 在 调 
用 pipe 时 ， 进 程 很 可 能 已 经 关闭 了 标准 输入 和 标准 输出 ， 调 用 pipe 函 数 时 ， 内 核 会 分 配 最 小 的 文件 描述 
符 ， 所 以 pipe 的 文件 描述 符 可 能 等 于 0 或 1。 在 这 种 情况 下 ， 如 果 没 有 if 判 断 加 以 保护 ， 代 码 就 变 成 了 : 














dup2 (1,1); 
close(1); 





这 样 的 话 ， 第 一 行 代码 什么 也 没 做 ， 第 二 行 代码 就 把 管道 的 写 入 端 给 关闭 了 ， 于 是 便 无 法 传递 信 
息 了 。 





9.1.6 与 shell 命 令 进 行 通信 (popen) 





管道 的 一 个 重要 作用 是 和 外 部 命令 进行 通信 。 在 日 常 编程 中 ， 经 常会 需要 调用 一 个 外 部 命令 ， 并 
且 要 获取 命令 的 输出 。 而 有 些 时 候 ， 需 要 给 外 部 命令 提供 一 些 内 容 ， 让 外 部 命令 处 理 这 些 输入 。Linux 
提供 了 popen 接 口 来 帮助 程序 员 做 这 些 事情 。 























就 像 system 函 数 ， 即 使 没有 system 函 数 ， 我 们 通过 fork、exec 及 wait 家 族 函 数 一 样 也 可 以 实现 system 
的 功能 。 但 终归 是 不 方便 ，system 函 数 为 我 们 提供 了 一 些 便 利 。 同 样 的 道理 ， 只 用 pipe 函 数 及 dup2 等 函 
数 ， 也 能 完成 popen 要 完成 的 工作 ， 但 popen 接 口 给 我 们 提供 了 便利 。 





popen 接 口 定 义 如 下 : 





#include <stdio.h> 
FILE *popen (Const char *command, const char *type); 
int pclose (FILE *stream); 

















popen 函 数 会 创建 一 个 管道 ， 并 且 创建 一 个 子 进程 来 执行 shell，shell 会 创建 一 个 子 进程 来 执行 
command。 根 据 type 值 的 不 同 ， 分 成 以 下 两 种 情况 。 








如 果 type 是 r: command 执 行 的 标准 输出 ， 就 会 写 入 管道 ， 从 而 被 调用 popen 的 进程 读 到 。 通 过 对 
popen 返 回 的 FILE 类 型 指针 执行 read 或 feets 等 操作 ， 就 可 以 读 取 到 command 的 标准 输出 ， 如 图 9-10 所 示 。 


J shell 进 程 
fork and exec fork and exec 


调用 popen 的 进程 人 执行 command 的 进程 








图 9-10 ”Ir 模 式 调用 popen 





如 果 type 是 w: 调用 popen 的 进程 ， 可 以 通过 对 FILE 类 型 的 指针 印 执行 write、fputs 等 操作 ， 负 责 往 管 
道里 面 写 入 ， 写 入 的 内 容 经 过 管道 传 给 执行 command 的 进程 ， 作 为 命令 的 输入 ， 如 图 9-11 所 示 。 








py 


fork and exec 


调用 popen 的 进程 
w 模式 





shell 进 程 


fork and exec 


oe 
标准 输入 





图 9-11 


popen 函 数 成 功 时 ， 








IO 结束 了 以 后 ， 可 以 调用 pclose 函 数 来 关闭 管 


Ww 模式 调用 popen 


会 返回 stdio 库 封装 的 FILE 类 型 的 指针 ， 失 败 时 会 返回 NULL， 并 且 设 置 errno。 
常见 的 失败 有 fbrk 失 败 ，pipe 失 败 ， 或 者 分 配 内 存 失败 。 








， 并 且 等 待 子 进 程 的 退出 。 尽 管 popen 函 数 返回 的 


是 FILE 类 型 的 指针 ， 也 不 应 调用 fclose 函 数 来 关闭 popen 函 数 打 开 的 文件 流 指针 ， 因 为 flose 不 会 等 待 子 
进程 的 退出 。pclose 函 数 成 功 时 会 返回 子 进 程 中 shell 的 终止 状态 。popen 函 数 和 system 函 数 类 似 ， 如 果 





command 对 应 的 命令 无 法 执行 ， 就 如 同 执行 了 exit (127) 一 样 。 如 果 发 生 其 他 错误 ，pclose 函 


1。 可 以 从 errno 中 获取 到 失败 的 原因 。 


下 面 给 出 


一 个 简单 的 例子 ， 来 示范 下 popen 的 用 法 : 


数 则 返 





#include<stdio.h> 
#include<stdlib.h> 
#include<unistd.nh> 
#include<string.h> 
#include<errno.h> 
#include<sys/wait.h> 
#include<signal.h> 
#define MAX LINE SIZE 8192 
void print wait exit(int status) 
{ 
printf("status = %d\n",status); 
if (WIFEXITED (status) ) 
{ 








printf("normal termination,exit status = $d\n",WEXITSTATUS (status)); 


} 
else if (WIFSIGNALED 
{ 





(status)) 


printf("abnormal termination,signal number =%d%$s\n", 


WTERMSIG (status), 
#ifdef WCOREDUMP 





WCOREDUMP (status) ?"core file generated" : 


#else 


"on) ， 
#endif 
} 
} 
int main(int argc ,char* argv[]) 


{ 
FILE *fp = NULL ; 


char command[MAX LINE SIZE],buffer[MAX LINE SIZE]; 


if(argc != 2 ) 
{ 


fprintf (stderr, "Usage: 
exit (1); 
} 
snprintf (command, sizeof (command), "cat $s" 
fp = popen (command, "r"); 
if (fp == NULL) 
{ 
fprintf (stderr, "popen failed ($s) 
exit (2) ， 


ss filename \n",argv[0]); 


rargv[1]); 


mn) ; 


", strerror (errno)); 


while (fgets (buffer,MAX LINE SIZE,fp) != NULL) 
{ 


fprintf (stdout,"%s",buffer); 
} 
int ret = pclose (fp); 
if(ret == 127 ) 
{ 
fprintf (stderr, "bad command : 


exit (3) ; 
else if(ret == -1) 
{ 
fprintf (stderr, "failed to get child status 
strerror (errno)); 
exit (4) ， 
} 
else 


{ 


print wait exit (ret); 


exit (0); 


Ss\n",command); 


(ss) \n™, 








将 文件 名 作为 参数 传递 给 程序 ， 执 行 cat filename 的 命令 。popen 创 建 子 进程 来 负责 执行 cat filename 


的 命令 





， 子 进程 的 标准 输出 通过 管道 传 给 父 进 程 





-> 


父 进 


程 所 


呈 可 以 通 





过 fgets 来 读 取 command 的 标准 输出 。 











popen 函 数 和 system 有 很 多 相似 的 地 方 ， 但 是 也 有 显著 的 不 同 。 调 用 System 函数 时 ，shell 命 令 的 执行 


被 封装 在 了 函数 内 部 ， 所 以 各 System 图 数 不 返回 








>» 调 月 












































由 system 的 进程 就 不 再 继续 执行 。 但 是 popen 函 数 不 











同 ， 一 旦 调用 popen 函 数 ， 调 用 进程 和 执行 command 的 进程 便 处 于 并 行 状 态 。 然 后 pclose 函 数 才 会 关闭 管 
道 ， 等 待 执行 command 的 进程 退出 。 换 名 话说， 在 popen 之 后 ，pclose 之 前 ， 调 用 popen 的 进程 和 执行 
command 的 进程 是 并 行 的 ， 这 种 差异 带 来 了 两 种 显著 的 不 同 : 

.在 并 行 期 间 ， 调 用 popen 的 进程 可 能 会 创建 其 他 子 进 程 ， 所 以 标准 规定 popen 不 能 阻塞 SIGCHLD 信 


号 。 这 也 意味 着 ，popen 创 建 的 子 进程 可 能 被 提前 执行 











pclose 函 数 时 ， 已 经 无 法 等 竺 command 子 进程 的 退出 ， 


等 符 操 作 所 捕 





若 发 生 这 种 情况 ， 调 用 


获 。 
这 种 情况 下 ， 将 返回 -1， 并 且 errno 为 ECHILD。 


.调用 进程 和 command 子 进程 是 并 行 的 ， 所 以 标准 要 求 popen 不 能 忽略 SIGINT 和 SIGQUIT 信 号 。 如 果 





是 从 键盘 产生 的 上 述 信号 ， 那 么 ， 调 用 进程 和 command 子 进程 








都 会 收 到 信号。 











节 介 绍 的 管道 也 被 称 为 无 名 管道 。 这 种 管道 因为 没有 实体 文件 与 之 关联 ， 靠 的 是 世代 相传 的 
文件 描述 符 ， 所 以 只 能 应 用 在 有 共同 祖先 的 各 个 进程 之 间 。 对 于 没有 亲缘 关系 的 任意 两 个 进程 之 间 ， 



































命名 管道 就 是 为 了 解决 无 名 管道 的 这 个 问题 而 引入 的 。FIFO 与 管道 类 似 ， 最 大 的 差别 就 是 有 实体 
文件 与 之 关联 。 由 于 存在 实体 文件 ， 不 相关 的 没有 亲缘 关系 的 进程 也 可 以 通过 使 用 FIFO 来 实现 进程 之 
间 的 通信 。 























与 无 名 管道 相 比 ， 命 名 管道 仅仅 是 披 了 一 件 马甲 ， 其 核心 与 无 名 管道 是 一 模 一 样 的 。 内 核 的 
人 /fifo.c 文 件 仅 有 153 行 ， 说 白 了 ， 这 简短 的 代码 只 干 了 两 件 事 : 











` 从 外 表 看 ， 我 是 一 个 FIFO 文 件 ， 有 文件 名 ， 任 何 进程 通过 文件 名 都 可 以 打开 我 。 











:我 的 内 心 与 无 名 管道 是 一 样 的 ， 文 持 的 文件 操作 与 无 名 管道 也 是 一 样 的 。 





9.2.1 创建 FIFO 文 件 


创建 命名 管道 的 接口 定义 如 下 : 








#include <sys/types.h> 
#include <sys/stat.h> 
int mkfifo(const char *pathname, mode t mode); 





其 中 ， 第 二 个 参数 的 含义 是 FIFO 文 件 的 读 写 执行 权利 ， 和 open 函 数 类 似 。 当 然 真实 的 读 写 执行 权 
限 ， 还 需要 按照 当前 进程 的 umask 来 取 掩 码 ， 即 : 














real mode = (mode & ~umask) 





除了 用 C 接 口 ， 还 可 以 用 命令 来 创建 一 个 命名 管道 : 





mkfifo [-m mode] pathname 











pathname 是 创建 命名 管道 文件 的 文件 名 ，-m mode 的 使 用 方法 和 chmod 的 方法 一 样 。 


除 此 外 ，mknod 命 令 也 可 以 用 来 创建 FFO 文 件 ， 使 用 方法 如 下 : 








mknod [-m mode] pathname p 





命令 末尾 的 p 表 示 要 创建 命名 管道 (named pipe) 。 














创建 出 来 的 FIFO 文 件 ， 用 1s-! 来 查看 ， 第 一 个 字母 是 p， 表 示 这 是 命名 管道 文件 。 








prw-rw-r-- 1 manu manu 0 2 月 


19 23:03 myfifo2 














在 shell 编 程 中 可 以 使 用 -p file 来 判断 是 否 为 FIFO 文 件 。 在 C 语 言 中 如 何 判 断 是 否 为 FIFO 文 件 呢 ? 通 
过 S_ISFIFO 宏 可 以 判断 ， 不 过 要 先 通 过 stat 或 fstat 函 数 来 获取 到 文件 的 属性 信息 ， 如 下 面 的 代码 所 示 : 

















#include <sys/types.h> 

#include <sys/stat.h> 

#include <unistd.h> 

int stat(const char *path, struct stat *buf); 
int fstat(int fd, struct stat *buf); 

S_ISFIFO (buf->st mode) 





9.2.2 ”打开 FIFO 文 件 

















一 且 FIFO 文 件 创建 好 了 ， 就 可 以 把 它 用 于 进程 间 的 通信 了 。 一 般 的 文件 操作 函数 如 open、read、write、close、unlink 等 都 可 以 用 在 FIFO 文 件 









































FIFO 文 件 和 普通 文件 相 比 ， 有 一 个 明显 的 不 同 : 程序 不 应 该 以 O_RDWR 模式 打开 FIFO 文 件 。POSIX 标 准 规定 ， 以 O_RDWR 模式 打开 FIFO 文 
件 ， 结 果 是 未 定义 的 。 当 然 了 ，Linux 提 供 了 对 O_RDWR 的 支持 ， 在 某 些 场景 下 ，O_RDWR 模 式 的 打开 是 有 价值 的 〈9.4 节 给 出 了 一 个 例子 〉。 



















































































对 FIFO 文 件 推荐 的 使 用 方法 是 ， 两 个 进程 一 个 以 只 读 模 式 (O_RDONLY) 打开 FIFO 文 件 ， 另 一 个 以 只 写 模 式 (O_WRONLY) 打开 FIFO 文 
件 。 这 样 负责 写 入 的 进程 写 入 FIFO 的 内 容 就 可 以 被 负责 读 取 的 进程 读 到 ， 从 而 达到 通信 的 目的 。 
















































































打开 一 个 FIFO 文 件 和 打开 普通 文件 相 比 ， 又 有 不 同 。 在 没有 进程 以 写 模式 (O_RDWR 或 O WRONLY) 打开 FIFO 文 件 的 情况 下 ， 以 
O_RDONLY 模 式 打开 一 个 FIFO 文 件 时 ， 调 用 进程 会 陷入 阻塞 ， 直 到 男 一 进程 以 0_WRONY (或 者 O_RDWR) 的 标志 位 打开 该 FIFO 文 件 为 止 。 同 
样 的 道理 ， 在 没有 进程 以 读 模式 (O_RDONLY 或 O RDWR) 打开 FIFO 文 件 的 情况 下 ， 如 果 一 个 进程 以 0_WRONLY 的 标志 位 打开 一 个 FIFO 文 
件 ， 调 用 进程 也 会 阻塞 ， 直 到 另 一 个 进程 以 0 RDONLY (或 者 O RDWR) 的 标志 位 打开 该 FIFO 文 件 为 止 。 也 就 是 说 ， 打 开 FIFO 文 件 会 同步 读 取 
进程 和 写 入 进程 。 






















































































































































































乍 看 之 下 ，O_RDONLY 模 式 打开 不 能 返回 ， 在 等 写 打开 ， 同 样 O0 WRONLY 打 开 不 能 返回 ， 在 等 读 打 开 ， 造 成 死 锁 ， 谁 都 返回 不 了 。 习 
不 是 这 样 的 。 当 O_RDONLY 打 开 和 O_WRONLY 打 开 的 请 求 都 到 达 FIFO 文 件 时 ， 两 者 就 都 能 返回 了 。 
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内 核 之 中 ， 维 护 有 引用 计数 r_counter 和 w_counter， 分 别 记录 FIFO 文 件 两 种 打开 模式 的 引用 计数 。 对 于 FIFO 文 件 ， 无 论 是 读 打 开 还 是 写 打 
开 ， 都 会 根据 引用 计数 判断 对 方 是 否 存 在 ， 进 而 决定 后 续 的 行为 (是 阻塞 、 返 回 成 功 ， 还 是 返回 失败 〉。 







































































FIFO 文 件 提供 了 O_NONBLOCK 标 志 位 ， 该 标志 位 会 显著 影响 open 的 行为 模式 。 将 O_RDONLY、O_WRONLY 及 O_NONBLOCK 三 种 标志 位 结 


合 在 一 起 考虑 ， 共 有 以 下 四 种 组 合 方式 ， 如 表 9-2 所 示 。 























表 9-2 ”打开 FIFO 文 件 的 不 同情 况 





打开 标志 位 行为 模式 
当 已 存在 写 打 开 该 FIFO 文件 的 进程 时 ， 成 功 返 回 
O_RDONLY 当 不 存在 写 打开 该 FIFO 文件 的 进程 时 ,会 陷入 阻塞 ， 直到 有 进程 以 


O_WRONLY 模式 (或 者 O_RDWR 模式 ) 打开 该 FIFO 文件 ， 方 能 返回 
当 已 存在 写 打 开 该 FIFO 文件 的 进程 时 ， 成 功 返 回 
当 不 存在 写 打 开 该 FIFO 文件 的 进程 时 ， 亦 成 功 返 回 
当 已 存在 读 打开 该 FIFO 文件 的 进程 时 ， 成 功 返 回 


O_WRONLY 当 不 存在 读 打 开 该 FIFO 文件 的 进程 时 ， 会 陷入 阻塞 ， 直 到 有 进程 以 
O_RDONLY 模式 (或 者 O_RDWR 模式 ) 打开 该 FIFO 文件， 方 能 返回 


当 已 存在 读 打 开 该 FIFO 文件 的 进程 时 ， 成 功 返 回 
当 不 存在 读 打 开 该 FIFO 文件 的 进程 时 ， 返 回 -1， 并 置 errno 为 ENXIO 


O RDONLY+O NONBLOCK 


O WRONLY+O NONBLOCK 



































同样 是 带 O_NONBLOCK 标 志 位 的 打开 ,没有 写 打开 进程 时 ， 读 打开 请 求 可 以 成 功 返 回 ， 但 没有 读 打开 进程 时 ， 写 打开 请 求 却 失败 ， 返 回 - 
1， 并 置 errno 为 ENXIO， 两 相 比 较 ， 是 否 太 不 公平 了 ? 




















这 样 设计 是 有 原因 的 : FIFO 只 有 读 取 端 ， 没 有 写 入 端 ， 并 无 显著 的 危害 ， 所 有 尝试 从 FIFO 中 读 取 数据 的 操作 都 不 会 返回 任何 数据 。 反 之 则 
不 然 。 如 果 人 允许 只 存在 写 入 端 ， 不 存在 读 取 端 ， 那 么 open 之 后 ， 所 有 向 FIFO 文 件 的 写 入 操作 ， 都 会 导致 SIGPIPE 信 号 的 产生 ， 以 及 write 调用 返回 
EPIPE 的 错误 ， 所 以 在 源头 上 堵 住 〈 即 让 open 函 数 返 回 失败 ) 反倒 更 加 合理 。 











































































































打开 FIFO 文 件 的 内 核 代 码 位 于 内 核 的 合 /fifo.c 文 件 中 ， 代 码 简短 ， 非 常 易 懂 。 读 者 可 以 通过 阅读 源 代 码 ， 加 深 对 打开 FIFO 文 件 的 理解 。 

















9.3 读 写 管道 文件 





无 名 管道 pipe 和 命名 管道 FIFO 在 内 核实 现 部 分 有 很 大 的 重合 ， 都 属于 管道 文件 系统 (pipefs〉。 无 名 管道 ， 分 裂 成 了 读 取 文 件 描述 符 和 写 入 
文件 描述 符 。 而 命名 管道 则 将 两 个 描述 符合 二 为 一 ， 如 果 是 读 打开 ， 就 如 同 获 取 到 了 无 名 管道 的 读 取 文件 描述 符 ， 如 果 是 写 打 开 ， 就 如 同 获取 
到 了 无 名 管道 的 写 入 文件 描述 符 。 这 种 本 质 上 的 一 致 ， 造 成 FIFO 的 读 写 控制 和 无 名 管道 的 读 写 控 制 是 一 模 一 样 的 ， 因 此 在 本 节 一 并 介绍 。 










































































影响 管道 或 FIFO 文 件 读 写 行为 的 因素 有 : 























:是 否 有 O_NONBLOCK 标 志 位 。 











-管道 的 最 大 容量 PIPE_BUF 和 要 读 写 的 字 节 数 n 的 关系 。 




















管道 文件 的 读 写 中 一 个 很 重要 的 标志 位 是 O NONBLOCK， 该 标志 位 会 影响 读 写 的 行为 模式 。 


三 





对 于 无 名 管道 ，Linux 提 供 了 特有 的 pipe2 函 数 ， 该 函数 的 接口 如 下 : 

















#define GNU SOURCE 
#include <unistd.h> 
int pipe2 (int pipefd[2], int flags); 





可 选 的 fag 就 有 O_NONBLOCK。 


对 于 命名 管道 FIFO， 打 开 文件 时 ， 可 以 带 上 O_NONBLOCK 标 志 位 来 控制 读 写 的 行为 (当然 了 ， 对 于 FIFO 文 件 ，O_NONBLOCK 也 会 影响 打 























开 的 行为 ) 。 
如 果 打 开 时 ， 忘 记 带 上 0O_NONBLOCK 标 志 位 ， 那 该 如 何 补 救 呢 ? 答案 是 














用 fenmtl 这 把 文件 控制 的 瑞士 军刀 。 














通过 如 下 代码 ， 可 以 给 管道 文件 加 上 O_NONBLOCK 标 志 位 : 























int flags = fcnt1 (fd, F_GETFL); 
flags |= O NONBLOCK 
fentl {fda; EE SETFL, 和 agey ; 






































相反 的 ， 如 果 打 开 时 ， 带 有 O_NONBLOCK 标 志 位 ， 而 后 面 又 想 取消 该 标志 位 ， 又 该 怎么 做 ? 





int flags = fentl (fd,F_ GETFL); 
flags &= ~O NONBLOCK; 
fcnt1 (fd,F_ SETFL, flags); 




















花 开 两 傈 ， 各 表 一 枝 。 先 来 说 说 从 FIFO 或 管道 读 取 端 读 ， 如 表 9-3 所 示 。 











表 9-3 ”从 一 个 包含 p 字 节 的 管道 或 FIFO 读 取 n 字 节 的 含义 





也 一 0 且 了 一 0 且 
存在 写 入 端 攻 术 符 尚 所 有 写 入 端 括 术 符 均 
未 关闭 已 关闭 


启用 O_NONBLOCK 失败 (EAGAIN) 返回 0 (EOF) 读 取 jp 字 节 和 


从 表 9-3 可 以 看 出 : 








“0O_NONBLOCK 标 志 位 影响 的 仅仅 是 当 管 道 为 空 并 且 存 在 写 入 端 时 的 行为 ， 读 取 操 作 的 行为 是 阻塞 ， 还 是 当即 返 

















可 失 败 。 
































: 当 read 返 回 0 时 ， 表 示 已 经 遇 到 了 EOF， 并 且 所 有 的 写 入 端 都 已 经 关闭 了 。 这 一 般 出 现在 管道 的 使 命 结 























束 时 ， 此 时 读 取 端 也 可 以 关闭 了 。 














说 完 读 ， 然 后 说 写 〈 如 表 9-4 所 示 ) 。 对 于 管道 的 写 入 而 言 ，POSIX 标 准 规定 ， 如 果 一 次 写 入 的 数据 量 不 超过 PIPE_BUF 个 字 节 ， 必 须 确保 写 




















入 是 原子 的 (atomic) 。 所 谓 原 子 是 指 : 写 入 的 内 容 必须 确保 是 连续 的 ， 纵 然 有 多 个 进程 同时 往 管道 
的 内 容 打 断 ， 本 次 写 入 的 内 容 不 会 混杂 其 他 进程 write 函数 写 入 的 内 容 。 标 准 规定 ，PIPE_BUF 最 少 为 12 字 节 ， 对 于 Linux 而 言 ， 这 个 值 是 4096， 
































一 个 页 面 的 大 小 。 


表 9-4 向 管道 写 入 n 字 节 





写字 节 数 n 夺 PIPE_BUF 


(保证 写 入 的 原子 性 ) Wa 
保证 写 J 原子 性 部 分 内 容 


使 命 必 达 的 策略 。 当空 闲 区 域 不 足 
写 入 字 节 数 m>PIPE_BUF 以 容纳 到 字 节 有 时， 陷入 阻塞 ， 待 管道 
(不 保证 写 入 的 原子 性 ) 空间 足够 时 再 写 2 。 但 成 功 返 回 时 ， 


L/w ee lm a Pp 
与 人 字 节 一 定 是 nn 











关于 单 次 写 入 的 长 度 超出 PIPE_BUF， 内 核 不 能 保证 其 原子 性 这 个 事实 ， 我 们 可 以 ; 


当空 闲 区 域 不 足以 容纳 n 字 节 时 ， 
陷入 阻塞 ， 等 待 读 取 进程 取 走 管道 的 























FP 写 入 ， 写 入 的 内 容 也 不 会 被 其 他 进程 写 入 








当 


尽 
返回 ， 
用 户 














有 NON_BLOCK 标志 位 
管道 空闲 区 域 不 足以 容纳 ” 字 


竹 时 ， 立 即 返 回 失 败 ， 并 置 errno 为 
EAGAIN 


力 而 为 的 策略 。 当 写 满 管道 时 ， 
实际 写 入 字 节 数 在 1~n 之 间 。 
需要 判断 返回 值 ， 来 确定 写 入 的 











个 简单 的 实验 来 验证 ， 示 例 代码 如 下 : 





#include <stdio.h> 
#include <stdlib.h> 
#include <string.h> 
#include <unistd.h> 
#include <sys/types.h> 
#include <errno.h> 
#include <fcnt1.h> 
#define BUF 4K 4*1024 
#define BUF 8K 8*1024 
#define BUF 12K 12*1024 
int main (void) 
{ 
char al[lBUF 4K]; 
char b[BUF 8K]; 
char Clo 12K]; 
(a 
(b 


memset TA', sizeof 全 这 
memset 'B';, Sizeof (DT 
memset (c, 'C', sizeof(c)); 


int pipefd[2]; 

int ret = pipe (pipefd); 

if (ret == -1) 

{ 
fprintf (stderr, "failed to create pipe (%s)\n",strerror(errno)); 
return 17 

a 

pid t pigd; 

pid = fork(); 

if (pid == 0) // 第 一 个 子 进程 


close (pipefd[0]); 
int loop = 0 
while (loop++ < 10) 
{ 
ret = write (pipefd[1], a, sizeof (a)); 
printf ("apid=%d write %d bytes to pipe\n", getpid(), ret); 
4 
exit (0); 
. 
pid = fork(); 
if (pid == 0) // 第 二 个 子 进程 


Close (pipefd[0]); 
int loop = 0; 
while (loop++ < 10) 
{ 
ret = write (pipefd[1], b, sizeof (b)); 
printf ("bpid=%d write %d bytes to pipe\n", getpid(), ret); 


exit (0)? 
a 
pid = fork(); 
if (pid == 0) // 第 三 个 子 进程 


Close (pipefd[0]); 
int loop = 0; 
while (loop++ <10) 
{ 


ret = write(pipefd[1], c, sizeof(c)); 
printf ("cpid=%d write %d bytes to pipe\n", getpid(), ret); 


exit (0) ， 
close (pipefd[1]); 
sleep (1); 
int fd = open("test.txt", O WRONLY | O CREAT | O TRUNC, 0644); 
char buf[1024*4] = {0}; 和 ml 
int n= 1; 
while (1) 
{ 


ret = read(pipefd[0], buf, sizeof (buf)); 
if (ret == 0) 


break; 


printf ("n=%02d pid=%d read %d bytes from pipe buf[4095]=%c\n", n++, getpid(), ret, buf[4095]); 


write (fd, buf, ret); 


return 0; 


























上 述 代码 ， 创 建 了 三 个 子 进程 ， 第 一 个 子 进 程 每 次 向 管道 写 入 4096 字 节 的 A 字 符 ， 循 环 10 次 ; 第 二 个 子 进程 向 管道 写 入 8192 字 节 (4096*2) 














的 B 字 符 ， 循 环 10 次 ; 第 三 个 子 进 程 每 次 向 管道 号 入 12288 字 节 (4096*3) 的 C 字 符 ， 循 环 10 次 。 父 进程 负责 从 








文件 。 





了 





























咱 


























管道 里 面 读 取 内 容 ， 















































行 ， 产 生 的 testtxt 文 件 也 不 相同 。 对 于 每 次 写 入 8SKB 和 每 次 写 入 12KB 的 情况 ， 尽 管 管道 
进程 的 写 入 。 


























多 次 执行 该 程序 ， 总 会 遇 到 某 次 8SKB 或 12KB 的 写 入 ， 中 间 混 杂 了 其 他 字符 。 下 面 的 




















于 三 个 子 进程 和 一 个 父 进程 是 同时 运行 的 ， 考 虑 到 进程 调度 的 因素 ， 每 次 执行 写 入 管道 和 从 管道 读 取 








不 保证 原子 性 ， 但 是 

















增 
三 
法 
衬 
& 
注 
Al 
es 
广 
湘 


的 时 序 并 不 完全 一 样 。 
其 内 容 也 不 是 每 次 都 必然 会 混入 其 他 





写 入 到 test.txt 


因此 每 次 执 

















0000000 4343 4343 4343 4343 4343 4343 4343 4343 


大 
0003000 4242 4242 4242 4242 4242 4242 4242 4242 
大 
0005000 4343 4343 4343 4343 4343 4343 4343 4343 
大 


0008000 4141 4141 4141 4141 4141 4141 4141 4141 
*0009000 4242 4242 4242 4242 4242 4242 4242 4242 
大 


0010000 4141 4141 4141 4141 4141 4141 4141 4141 


Es 


0015000 4343 4343 4343 4343 4343 4343 4343 4343 
*002d000 4242 4242 4242 4242 4242 4242 4242 4242 


002e000 4141 4141 4141 4141 4141 4141 4141 4141 


大 


0030000 4242 4242 4242 4242 4242 4242 4242 4242 
大 
0032000 4141 4141 4141 4141 4141 4141 4141 4141 
大 


0033000 4242 4242 4242 4242 4242 4242 4242 4242 


大 


0035000 4141 4141 4141 4141 4141 4141 4141 4141 
大 


0036000 4242 4242 4242 4242 4242 4242 4242 4242 


大 


003c000 





























从 地 址 002d000 到 地 址 002e000， 只 有 4KB 的 大 小 ， 可 是 里 面 的 内 容 却 是 0x42 即 B 字 符 。 从 程序 可 以 得 知 ，B 字 符 每 次 写 入 8SKB， 这 里 却 
4KB 的 内 容 ， 地 址 002d000 之 前 是 C 字 符 ，002e000 之 后 是 A 字符 。 唯 一 的 解释 就 是 某 次 8KB 的 写 入 内 容 被 中 























多 次 执行 程序 ， 解 读 输出 的 内 容 ， 从 某 些 输出 中 可 以 看 出 ，8KB 的 写 入 和 12KB 的 写 入 ， 都 不 是 原子 的 。 


























和 写 入 内 容 长 度 不 超过 PIPE_BUF 时 ， 内 核 确保 写 入 操作 是 原子 的 这 条 性 质 非 常 重 好 





， 尤 其 是 在 有 多 个 进程 向 管道 












































的 消息 ， 否 则 会 时 致 无 法 正确 解析 消息 的 内 容 。 





途 打 断 ， 混 杂 了 









































只 有 
其 他 进程 的 写 入 。 


写 入 的 情况 下 。 在 不 采取 








其 他 同步 手段 的 情况 下 ， 消 息 体 小 于 PIPE_BUF 时 ， 写 入 管道 是 安全 的 ， 即 使 多 个 进程 一 起 写 入 也 没关系 ， 内 核 会 保证 写 入 内 容 不 会 和 其 他 i 
的 写 入 内 容 混在 一 起 。 但 是 如 果 消 息 体 太 大 ， 长 度 超过 了 PIPE_BUF， 就 要 警惕 ， 需 要 采取 必要 的 同步 措施 ， 来 确 


[3 





保 消 息 内 容 不 会 混杂 其 他 ; 


攻 




















9.4 使 用 管道 通信 的 示例 


前 文 介绍 了 无 名 管道 pipe 和 命名 管道 FFO， 了 解 了 它们 的 很 多 性 质 ， 但 是 到 目前 为 上 上， 还 没有 介 
绍 如 何 利用 管道 来 实现 进程 间 通 信 。 











下 面 以 FIFO 为 例 ， 介 绍 如何 使 用 管道 来 实现 一 个 客户 端 /服务 器 的 应 用 程序 ， 有 共 体 流程 如 图 9-12 所 








服务 天 进程 





只 写 法 写 打开 ， 但 是 只 污 只 写 
(服务 器 回应 ) 读 号 打开 ,但 是 只 读 服务 器 回应 ) 


区 Public FIFO 
Private FIFO 1 只 写 只 写 


J 
只 读 (客户 端 请 求 ) (客户 端 请 求 ) 











客户 端 进程 


客户 端 进 程 








图 9-12 ”使 用 FIFO 实 现 客户 端 服务 器 通信 








首先 服务 器 进程 会 创建 一 个 公开 的 众所周知 的 命名 管道 文件 ， 我 们 称 之 为 Public FIFO， 服 务 器 进 
程 以 0 RDWR 的 模式 打开 ， 但 是 ， 服 务 器 进程 只 会 从 Public FIFO 中 读 取 内 容 ， 而 不 会 向 该 命名 管道 中 
写 入 内 容 。 之 所 以 服务 器 进程 要 以 O_RDWR 模式 打开 (而 不 是 O_RDONLY 模 式 打 开 〉 ， 是 因为 服务 器 
进程 是 daemon 进 程 ， 当 所 有 的 客户 端 都 关闭 曾经 打开 的 Public FIFO， 只 有 自身 也 以 写 模式 打开 Public 
FIFO， 服 务 器 进程 的 read 才 不 会 返回 9， 而 是 继续 阻塞 在 管道 ， 等 待 新 的 客户 发 来 请 求 。 
































server fifo fd = open (PUBLIC FIFO NAME,O RDWR); 





这 个 Public FIFO 是 众所周知 的 ， 所 有 向 服务 器 进程 发 送 请 求 的 客户 端 程序 都 应 该 知道 该 Public FIFO 
的 路 径 。 一 般 来 讲 ， 客 户 端 会 将 自己 的 请 求 作为 消息 体 写 入 Public 管 道 之 中 。 除 此 以 外 ， 客 户 端 会 负责 
创建 一 个 私有 的 FIFO， 用 来 和 服务 器 进程 进行 通信 。 服 务 器 进程 从 管道 中 读 取 了 请 求 之 后 ， 就 会 十 分 
默契 地 将 回应 写 入 到 该 客户 端 创建 的 私有 的 FIFO 中 。 









































问题 来 了 ， 服 务 器 进程 如 何 知道 该 往 哪 个 私有 的 FIFO 里 面 号 入 ， 对 应 的 客户 端 进程 才能 读 到 回应 
言 息 ? 方法 有 很 多 ， 比 如 客户 端 可 以 将 自己 私有 的 FIFO 路 径 作为 请 求 的 一 部 分 ， 写 入 到 Public FIFO 
中 ， 服 务 器 进程 可 以 从 请 求 中 获得 对 应 客户 端的 私有 FIFO 路 径 。 还 有 一 种 方法 是 ， 私 有 FIFO 有 一 定 的 
命名 规范 ， 比 如 /tmp/fifo.client pid， 其 中 client pid 代 表 客 户 端 进程 的 进程 ID。 只 要 客户 端 发 到 Public 


















































FIFO 的 内 容 中 包含 自己 的 PID， 服 务 器 进程 就 能 根据 事先 的 约定 找到 对 应 的 私有 FIFO 文 件 ， 从 而 可 以 将 
响应 写 入 对 应 的 私有 FIFO 中 。 


上 述 的 模型 解决 了 如 何 利 用 FIFO 编 写 客户 端 /服务 器 程序 这 个 问题 。 一 般 来 说 ， 不 会 采用 迭代 服务 











的 方式 。 因 为 某 些 客户 请 求 处 理 起 来 可 能 非常 耗 时 ， 那 么 其 他 客户 端 发 过 来 的 请 求 就 会 被 阻 赛 ， 得 不 








到 及 时 响应 。 比 较 第 见 的 是 提供 并 发 服务 ， 即 每 取出 一 个 请 求 ， 就 创建 一 个 进程 或 一 个 线程 来 啊 应 该 
请 求 。 当 然 还 可 以 提供 线程 池 ， 让 空闲 的 线程 来 负责 处 理 客户 的 请 求 。 














然而 ， 还 有 一 个 关键 的 因素 没有 讨论 。 事 实 上 ， 客 户 端 写 入 的 内 容 并 不 是 结构 化 的 消息 ， 写 入 管 


道 之 后 ， 客 户 端 进程 写 入 的 不 过 就 是 字 贡 流 。 那 么 ， 多 个 进程 都 向 管道 号 入 时 ， 如 何 正 确 地 区 分 内 容 
的 边界 ， 正 确 地 拣 出 每 个 进程 的 发 送 内 容 就 成 了 通信 的 关键 。 








一 般 来 说 ， 为 了 区 分 内 容 的 边界 ， 有 以 下 办 法 : 
` 写 入 内 容 为 固定 长 度 。 


特殊 分 隅 字符 。 





具有 长 度 字 段 的 头 。 





NY 


固定 长 度 的 方法 最 简单 ， 也 最 容易 想到 ， 但 是 对 管道 空间 的 使 用 效率 不 高 ， 如 图 9-13 所 示 。 写 入 
的 内 容 长 度 固定 ， 意 味 着 不 得 不 采用 最 长 消息 的 长 度 作 为 固定 长 度 。 对 于 消息 体 长 度 参 差 不 齐 ， 短 消 
县 占 大 多 数 而 最 长 消息 的 长 度 又 很 长 的 情况 ， 效 率 太 低 ， 大 大 降低 了 管道 容纳 消息 的 能 


一 一 n 字 节 一 和 一 n 字 节 下 n 字 节 一 一 


图 9-13 ”固定 长 度 的 消息 
































特殊 分 隔 字符 也 是 一 种 常用 的 方法 ， 如 图 9-14 所 示 。 比 如 事先 约定 消 恩 的 最 后 一 个 字符 总 是 换行 
符 。 这 种 方法 有 几 个 次 端 : 











sy br 


字符 撞车 ， 如 果 消 息 体 中 真 的 存在 事先 选 定 的 特殊 字符 ， 那 就 不 得 不 转 义 。 


特殊 分 隔 字符 


图 9-14 ”特殊 分 隔 字 符 为 结尾 的 消息 











具有 长 度 字 段 的 头 是 比较 推荐 的 方法 ， 如 图 9-15 所 示 。 管 道中 提取 消息 分 成 两 步 : 





1) 提取 消息 的 长 度 ， 由 于 长 度 字段 本 身 的 长 度 是 固定 的 ， 所 以 不 会 有 问题 。 





2) 根据 第 一 步 读 取 的 消息 长 度 len， 读 取 接 下 来 的 len 字 节 内 容 作为 消息 体 。 


图 9-15 ”以 长 度 字段 作为 头 的 消息 











值得 一 提 的 是 ， 从 内 核 版 本 3.4 开 始 ， 内 核 开 始 提供 Packet 模 式 的 管道 。 所 谓 Packet 模 式 ， 就 是 写 入 
管道 的 内 容 就 像 是 一 个 packet， 或 者 说 是 一 个 消息 ， 而 不 是 原始 的 字 节 流 。 











ret = pipe2 (pipefd,O DIRECT) 





当 打 开 管 道 时 ， 带 上 0O_DIRECT 标 志 位 ， 创 建 的 管道 就 是 Packet 模 式 的 管道 ， 代 码 如 下 所 示 。 当 然 
了 ， 老 版 本 的 Linux 不 支持 O_ DIRECT 标志 位 ， 会 返回 EINVAL 错 误 。 





当 写 入 Packet 模 式 的 管道 时 ， 如 果 写 入 内 容 少 于 PIPE BUF， 该 内 容 仍然 完全 占有 一 个 页 面 。 后 面 
的 号 入 《不 管 是 本 进程 还 是 其 他 进程 ) 不 会 与 上 一 次 的 写 入 共用 一 个 页 面 。 当 写 入 内 容 大 于 PIPE_BUF 
时 ， 会 分 成 多 个 包 。 














从 Packet 模 式 管道 中 读 取 时 ， 存 放 读 取 内 容 的 buffsrx 有 PIPE BUF 大 小 肯定 足够 了 。 如 果 指 定 的 buffer 
太 小 ， 小 于 下 一 个 要 取出 的 Packet 的 大 小 ， 管 道 仍 然 是 取出 Packet 大 小 ， 超 出 buffer 的 部 分 会 被 丢弃 掉 而 
不 是 仍旧 留 在 管道 的 内 存 缓冲 区 。 








呈 








这 种 模式 从 使 用 内 存 的 角度 来 看 有 点 浪费 ， 因 为 不 管 消息 多 大 ， 都 会 至 少 占有 1 个 页 面 的 大 小 。 但 
是 从 编程 的 角度 来 看 接口 更 容易 使 用 。 


第 10 间 ”进程 间 通 信 : System V IPC 
下 面 三 种 类 型 的 进程 间 通 信 方 法 统称 为 System V IPC: 
:System V 消 息 队 列 
.SystemV 信 和 号 量 


:System V 共 享 内 存 





这 三 种 了 PC 机 制 的 差别 很 大 ， 之 所 以 将 它们 放 在 一 起 讨论 ， 一 个 习 








要 的 原因 是 这 三 种 机 制 是 一 同 被 
开发 出 来 的 。 它 们 最 早出 现在 20 世 纪 70 年 代 末 ，1983 年 三 者 出 现在 主流 的 System V Unix 系 统 上 ， 因 此 这 
三 种 机 制 被 统称 为 System V IPC。 

















10.1 System V IPC 概 述 
System V IPC 相 关 的 接 
关 奖 件 


关联 数据 结构 
创建 或 打开 对 象 
关闭 对 象 


控制 


时 作 


执行 IPC 


从 作用 上 看 ， 


System V IPC 未 遵循 “一 切 都 是 文件 



































get 调 用 《〈 表 10-1 中 


System V PC 对 
无 论 是 否 存 在 亲缘 关系 ， 只 要 有 


程 ， 


System V IPC 对 
删除 操作 或 系统 重启 
此 外 ， 我 们 也 无 法 像 操 
操作 函数 来 访问 它 或 修改 它 





的 “ 包 


建 或 打 




















象 的 作 











于 对 象 "一 行 ) ， 


围 是 整个 操作 系统 ， 





| 沁 


如 表 10-1 所 示 。 


表 10-1 


<sys/msg.h> 


gsnd 
msgrev() 


三 种 通信 机 制 各 不 相同 ， 但 是 从 设计 和 实现 的 角 























>” 的 Unix 哲 学 ， 而 是 采 


























有 








象 














内 核 持久 性 。 








后 面 











口 ， 





作文 件 











对 象 ， 无 法 
































rm 将 











的 届 








性 。 


其 删除 ， 也 无 法 月 








一 样 
所 以 不 得 不 提供 
有 chmod 来 修改 它们 站 








一 些 不 便 之 处 。 

















相应 的 权限 ， 者 


HL、 Ar 


于 System V IPC 对 象 不 是 文件 描述 符 


标 识 


内 核 没 有 维护 引用 计数 。 


System V IPC 编 程 接 


<sys/sem.h> 





口 





共享 内 存 
<sys/shm.h> 

shmid ds 

shmget() + shmat() 
无 

shmctl() 


访问 共享 内 存 区 的 内 存 数据 








度 来 看 ， 还 是 有 很 











一 个 整 型 标识 符 ID，System VIPC 后 续 




































































了 可 以 通过 操作 System V IPC 对 


哪怕 创建 System VIPC 对 象 的 进程 
启动 的 进程 依然 可 以 使 月 




















已 经 退出 ， 





调用 各 种 get 函 数 返 
象 来 达到 通信 的 








风格 一 致 的 地 方 。 


只 符 ID 和 键 值 来 标识 一 个 System V IPC 对 象 。 每 种 System V IPC 都 有 一 个 相关 的 


的 函数 操作 都 要 作用 在 该 标识 符 ID 上 。 



































回 的 人 D 是 操作 系统 范围 内 的 标识 符 ， 对 于 任何 进 


的 。 






























































不 执行 














那 伯 有 一 段 时 间 没 有 任何 进程 打开 该 IPC 对 象 ， 只 

















昌之 前 创建 的 System V IPC 对 象 来 通信 。 





来 操作 System V IPC 对 象 。System V IPC 对 象 在 文件 
专门 的 系统 调 月 
的 访问 权限 。 幸 好 Linux 提 供 


























文件 














， 所 以 无 法 使 用 基于 


月 〈 如 msgctl、semop 等 ) 来 
了 ipcs、ipcrm 和 ipcmk 等 命令 来 操作 这 些 对 象 。 


述 符 的 多 路 转 接 1/O 技 术 (select、poll 和 epoll 等 )。 





系统 中 没有 实体 文件 与 之 关联 。 我 们 不 能 用 文件 相关 的 
如 作 这 些 对 象 。 在 shell 中 无 法 用 ls 查看 存在 的 IPC 
































这 个 缺点 会 给 编程 带 来 





10.1.1 标识 符 与 PC Key 


System V IPC 对 象 是 靠 标识 符 了 来 识别 和 操作 的 。 该 标识 符 要 具有 系统 
能 毫 不 相干 。 但 是 PC 的 标识 


台 b 启 ; 


程 的 文件 描述 符 4 和 另 一 个 进程 的 文件 描述 符 4 可 











:证 


























且 有 相应 的 权限 ， 任 何 进程 都 可 以 

















三 种 了 PC 对 象 操作 的 起 点 都 是 调 














通过 标识 符 进 行进 程 间 通 信 。 









































局 变量 ， 





符 呈 是 操作 系统 的 全 























用 相应 的 get 函 数 来 获取 标识 符 D， 如 消息 队列 的 get 函 数 为 : 


人 一 性 。 这 和 文件 描述 符 不 同 ， 文 件 描述 符 是 进程 内 有 效 的 。 
只 要 知道 该 值 〈 哪 怕 是 猜测 获得 的 ) 














个 进 








int msgget (key t key, int msgflg); 




















其 中 第 一 个 参数 是 key t 类 型 ， 它 划 
的 不 同 ， 会 有 不 同 的 控制 逻辑 ， 如 表 10-2 所 示 。 
































oflag 参数 
无 特殊 标志 
IPC CREAT 
IPC_CREAT |IPC EXCL 


实 是 一 个 整 型 的 变量 








。]PC 的 get 函 数 将 key 转 换 成 相应 的 人 PC 标识 符 。 根 据 亿 C get 函 数 


成 功 返 回 0, 创建 新 标识 符 





成 功 返 回 0， 创 建新 标识 符 





表 10-2 ”创建 或 打开 一 个 IPC 对 象 的 逻辑 


出 错 返 回 -1(ENOENT) 





出 错 返回 -1(EEXIST) 








口 

















jIPC 的 get 函 数 总 是 返 











AP 


因为 key 可 以 产生 了 PC 标识 符 ， 








对 象 
删除 或 系统 重 

















这 





key 公 





启 后 ， 则 重新 使 




















不 同 进程 可 通过 同 








对 于 key 的 选择 ， 存 在 以 下 三 种 方法 。 








第 一 种 方法 是 随机 选择 一 个 整数 值 作为 key 





的 生命 周期 中 ，key 到 标识 符 卫 的 映射 是 稳定 不 变 的 ， 即 同 
建 的 新 的 耻 C 对 象 被 分 配 的 标识 符 很 可 能 是 不 同 的 。 


所 以 很 容易 产生 一 种 误解 ， 就 是 同 


个 key 调 


的 


key 已 经 存在 
成 功 返 回 0， 获 取 到 已 有 标识 符 
成 功 返 回 0， 获 取 到 已 有 标识 符 


第 二 个 参数 oflag 


= 





同一 个 整 型 值 。 实 际 上 并 非 如 此 。 在 IPC 























口 





















































要 包含 该 头 文件 。 
到 的 所 有 






































需要 注意 的 是 ， 要 防止 无 意 中 选 择 了 村 
key 放 入 同一 个 头 文件 中 ， 这 样 就 可 以 方便 地 检查 是 否 有 重复 的 key 值 。 








个 key 调 | 


个 key 获 取 标 识 符 ID， 进 而 操作 同一 个 System V IPC 对 象 。 那 么 现在 问题 就 演变 成 了 如 何 选择 key。 


值 “ 如 图 10-1 所 示 ) 。 作 为 key 
EE 复 的 key 值 ， 从 而 导致 不 需要 通信 的 进程 之 间 意 外 通信 ， 以 致 引发 程序 混乱 。 一 个 技巧 











数 ， 总 是 返回 相同 的 标识 符 ID。 但 是 





jj get 也 | 














所 有 























值 的 整数 通常 被 放 在 一 个 头 文件 中 ， 

















IPC 
对 象 











内 核 层 




















和 一 


第 二 种 方法 是 使 用 











应 用 层 


IPC 标 识 各 


Magic number 
Ox1234 


图 10-1 


IPC PRIVATE， 使 用 方法 如 下 : 








使 





jmagic number 作 为 key 











且 key 对 应 的 耻 C 对 象 被 


使 用 该 PC 对 象 的 程序 都 





id = msgget (IPC PRIVATE,S_IRUSR | S_IWUSR); 





这 种 方法 无 须 指定 了 PC_CREATE 和 IPC_EXCL 标 志 位 ， 就 能 创建 一 个 新 的 了 PC 对 象 。 使 用 了 PC_PRIVATE 时 总 是 会 创建 新 的 了 PC 对 象 ， 从 这 个 角 


度 看 将 其 称 之 为 IPC_NEW 或 许 更 合理 。 





不 过 ， 使 用 IPC_PRIVATE 来 得 到 IPC 标 识 符 会 存在 一 个 问题 ， 








创建 一 个 新 的 了 PC 对 象 ， 如 图 10-2 所 示 。 














口 4 





大 | 





即 不 相干 的 进程 无 法 通过 key 值 得 到 同一 个 IPC 标 识 符 。 




















为 IPC_PRIVATE 总 是 

















XN 




















因此 IPC_PRIVATE 一 般 














于 父子 进程 ， 父 


进程 调用 fork 之 前 创建 IPC 对 象 ， 创 建 子 进程 后 ， 子 进程 也 就 继 











承 了 IPC 标 识 符 ， 从 而 父子 进程 可 以 通信 。 当 然 无 亲缘 关系 的 进程 也 可 以 使 用 耻 C_PRIVATE， 只 是 稍微 麻烦 了 一 点 ， 了 PC 对 象 的 创建 者 必须 想 办 
法 将 IPC 标 识 符 共享 出 去 ， 让 其 他 进程 有 办 法 获取 到 ， 从 而 通过 IPC 标 识 符 进 行 通 信 。 

















内 核 层 


应 用 层 
IPC 标 识 符 IPC 标 识 符 


IPC_PRIVATE IPC_PRIVATE 





图 10-2”IPC_PRIVATE 总 是 创建 新 的 PC 对 象 














第 三 种 方法 是 使 用 ftok 函 数 ， 根 据 文件 名 生成 一 个 key。ftok 是 file to key 的 意思 ， 多 个 进程 通过 同一 个 路 径 名 获得 相同 的 key 值 ， 进 而 得 到 同一 
个 人 PC 标识 符 。 其 使 用 方法 如 图 10-3 所 示 。 
































IPC 
内 核 层 


应 用 层 
IPC 标 识 符 





pathname 


图 10-3 ”根据 文件 获得 key， 进 而 获得 IPC 标 识 符 


fiok 函 数 接口 的 定义 如 下 : 








#include <sys/types.h> 
#include <sys/ipc.h> 
key 七 ftok (const char *pathname, int proj iqd); 








在 Linux 实 现 中 ， 该 接口 把 通过 path-name 获 取 的 信息 和 传 入 的 第 二 个 参数 的 低 8 位 灶 合 在 一 起 ， 得 到 一 个 整 型 的 PC key 值 ， 如 图 10-4 所 示 。 
需要 注意 的 是 ，pathname 对 应 的 文件 必须 是 存在 的 。 








这 个 函数 在 Linux 上 的 实现 是 : 按照 给 定 的 路 径 名 ， 获 取 到 文件 的 stat 信 息 ， 从 stat 信 息 中 取出 st_dev 和 st_ino， 然 后 结合 给 出 的 proj id， 按照 


图 10-4 所 示 的 算法 获取 到 32 位 的 key 值 。 
文件 所 在 设备 的 
次 设备 号 的 低 8 位 


图 10-4 fiok 生 成 键 值 的 算法 





可 以 用 程序 来 验证 ， 代 码 如 下 : 








#include <stdio.h> 
#include <unistd.h> 
#include <sys/stat.h> 
#include <sys/types.h> 
#include <sys/ipc.h> 
int main(int argc , const char* argv[]) 
{ 
struct stat stat buf ; 
if(argc != 2) 加 
{ 


fprintf (stderr,"Usage : ftok <pathname>"); 
return 1; 


} 
stat (argv[1],&stat buf); 


key t key = ftok(argv[1],0x1234) ， 

printf("st dev : %lx, st inode : S1X ， 
stat buf.st dev,stat buf.st ino, 

return 0; i 和 i 

} 


执行 情况 如 下 : 


人 
key); 





./ftok test.c 
st dev : 801, st inode : 240cb4 , key : 34010cb4 














观察 上 面 的 加 粗 部 分 ， 可 以 看 























文件 映射 出 同一 个 key 值 的 情况 。 这 号 




















.两 个 文件 所 


























两 个 文件 在 各 自 的 文件 系统 上 的 inode 























.两 个 进程 分 别 选择 











虽然 理论 上 是 存在 key 值 六 
则 很 难 出 现 。 因 此 使 









































出 key 确 实 是 按照 区 





10-4 所 示 的 数据 来 源 灶 合 而 得 到 的 。 即 使 是 fok 函 数 的 第 二 个 参数 相同 


了 可 能 发 生 的 。 这 种 六 

















且说 的 是 很 难 ， 








不 是 绝对 不 会 ， 因 为 这 种 情况 是 

















属 文件 系统 所 在 磁盘 的 次 设备 号 的 低 8 位 相同 。 


的 最 低 16 位 也 相同 。 


对 同一 个 proj_id 来 调用 ftok( ) 来 下 





突 的 可 能 ， 但 是 实际 上 ， 不 同 的 文件 
































冲突 的 key 值 的 可 能 性 太 低 ， 除 非 刻意 构造 这 种 冲突 ， 





jftok 函 数 来 获取 key 值 是 编程 




















， 也 很 难 出 现 两 个 

















突 的 出 现 需 要 同时 满足 下 面 三 个 条 

















否 


10.1.2 IPC 的 公共 数据 结构 

















三 种 System V IPC 对 象 有 很 多 共性 ， 从 代码 层面 上 看 也 有 很 多 公共 的 部 分 。 权 限 结构 就 是 其 中 一 个 。IPC 的 权限 结构 至 少 包括 如 下 成 员 : 




















struct ipc perm{ 
key t key; 
过 可 t vidy 
gid t gid; 
uid t cuids 
gid t cgid; 
mode t mode; 
ulong t seq; 


i 
/消息 队列 控制 相关 的 结构 体 


/ 
struct msqid ds { 
struct ipc perm msg perm; 


和 
/* 信 号 量 控制 相关 的 结构 体 


Wy 
struct semid ds { 
struct ipc perm sem perm; 


} 
/* 共 享 内 存 控制 相关 的 结构 体 


Wp 
struct shmid ds { 
struct ipc perm shm perm; 


和 






































uid 和 和 gid 字段 用 于 指定 PC 对 象 的 所 有 权 。cuid 和 cgid 字 段 保存 着 创建 该 PC 对 象 的 进程 的 有 效用 户 人 DD 和 有 效 组 DD。 初 始 情况 下 ， 用 户 
ID (uid) 和 创建 者 ID 〈cuid) 的 值 是 相同 的 。 它 们 都 是 调用 进程 的 有 效 ID。 但 是 创建 者 ID 〈cuid) 是 不 可 以 改变 的 ， 而 所 有 者 岂 则 可 以 通过 
IPC_SET 来 改写 。 下 面 的 代码 演示 了 如 何 修改 共享 内 存 的 vid 字段 : 













































































struct shmid ds shm ds; 
if (shmctl (id, IPC STAT, gshm ds)) 一 -1 
{ 
/*error handler*/ 
} 
shm ds.shm perm.uid = newuid; 
if (shmctl (id, IPC SET,&shm ds) == -1) 


/*error handle*/ 


} 










































































mode 是 用 来 控制 读 写 权 限 的 。 所 有 的 System V IPC 对 象 都 不 具备 执行 权限 ， 只 有 读 写 权限 。 其 中 对 于 信号 量 而 言 ， 写 权限 意味 着 修改 权限 。 
IPC 对 象 的 权限 控制 见 表 10-3。 











表 10-3 ”IPC 对象 的 权限 控制 


权 限 标 志 位 位 


和 文件 的 权限 有 点 类 似 ，IPC 对 象 的 权限 被 分 成 了 三 类 : owner、group 和 other。 创 建 对 象 时 可 以 为 各 个 类 别 设 定 不 同 的 访问 权限 ， 代 码 如 下 
所 示 : 




















msg_ id = msgget (key,IPC CREAT | S IRUSR | S_IWUSR |S_IRGRP); 
msg_id = msgget (key, IPC CREAT | 0640); 





当 一 个 进程 尝试 对 IPC 对 象 执行 某 种 操作 的 时 候 ， 首 先 会 检查 权限 。 检 查 的 逻辑 如 下 : 


























> 








:如 果 进 程 是 特权 进程 ， 那 么 进程 拥有 对 IPC 对 象 的 所 有 权限 。 











所 有 者 或 创建 者 ID 匹配 ， 那 么 





:如 果 进 程 的 有 效用 户 ID 与 IPC 对 象 的 












































“如 果 进 程 的 有 效 

















否则 ， 将 他 C 对 象 的 other 权 限 赋予 进程 。 





会 将 对 象 的 owner 的 权限 赋 给 


合 进 程 。 


户 ID 或 任意 一 个 辅助 组 ID 与 PC 对 象 的 所 有 者 组 ID 或 创建 者 组 ID 匹配 ， 那 么 会 ; 


口 














年 IPC 对 象 的 group 的 权限 赋予 进程 。 

























































































































































































































































































数据 结构 ipc_perm 中 的 key 和 seq 也 很 有 意思 。key 比 较 简 单 ， 就 是 调用 get 函 数 创建 下 C 对 象 时 传递 进去 的 key 值 。 如 果 key 的 值 是 
IPC _ PRIVATE， 则 实际 的 key 值 是 0。 

和 key 相 比 ， 成 员 变 量 seq 就 不 那么 好 理解 了 。 进 程 分 配 文件 描述 符 时 采用 的 是 最 小 可 用 算法 。 比 如 文件 描述 符 5 曾 经 被 分 配给 文件 A， 但 是 
很 快 进程 关闭 了 文件 A。 如 果 进 程 尝 试 打开 另外 一 个 文件 ， 此 时 如 果 5 是 最 小 可 用 的 槽 位 ， 那 么 新 打开 文件 的 文件 描述 符 就 是 s。 但 是 PC 对 象 的 
标识 符 ID 分 配 不 能 采用 这 个 算法 。 因 为 多 个 进程 要 通过 标识 符 ID 来 通信 ， 而 标识 符 ID 是 整个 系统 内 有 效 的 。 如 果 采 用 最 小 可 用 的 算法 ， 一 般 来 
讲 ，IPC 对 象 的 个 数 不 会 太 多 ， 那 么 这 个 数字 很 容易 就 被 猜 到 了 。 举 例 来 说 ， 如 果 存 在 一 个 恶意 程序 要 攻击 消息 队列 ， 它 只 需 尝 试 很 小 范围 内 的 
数字 ， 就 可 以 猜 到 了 PC 对 象 的 标识 符 ID， 进 而 偷偷 取 走 消息 队列 里 面 的 信息 。 



























































内 核 针 为 每 一 种 System V IPC 维 护 了 一 个 ipc_ids 类 型 的 结构 体 。 该 结构 体 的 组 成 如 图 10-5 所 示 。 











sem ids 


max_seq 
PCSP1dr 


图 10-5 System VIPC 的 ipc_ ids 数 据 结构 


max_seq 
ole 六 (ebe 





























上 述 结构 体 中 in_use 字 段 记录 的 是 系统 当前 在 





的 IPC 个 数 。 因 此 创建 PC 对 象 时 ， 该 值 会 加 1; 


















































结构 体 中 seq 字 段 记 录 了 开机 以 来 创建 该 PC 对 象 的 流水 号 。 创 建 时 seq 的 值 自 加 ， 但 是 销毁 的 时 1 
对 象 的 创建 而 单调 地 递增 ， 直 到 递增 到 上 限 (max_seq) ， 再 溢出 回 绕 ， 重 新 从 0 开始 。 



































的 了 PC 对 象 时 ， 三 种 了 PC 对 象 的 创建 都 会 走 到 ipc_addid 函 数 处 ， 如 图 10-6 所 示 。 









ipc addid 
pomuilcd 


图 10-6 “为 新 的 PC 对 象 生成 标识 符 ID 





ipc_addid 函 数 会 初始 化 了 PC 对 象 的 很 多 成 员 变 量 ， 比 如 权限 相关 的 uid、gid、cuid 和 cgid， 也 会 维 








创建 新 的 信号 量 创建 新 的 消息 创建 新 的 共享 内 存 
newary 队列 newmsg newseg 


:eee 


候 seq 的 值 并 不 会 自 减 。 

















护 该 PC 对 象 的 seq 值 。 


销毁 IPC 对 象 时 ， 该 值 会 减 去 1。 


seq 的 值 随 着 该 种 PC 








int ipc addid(struct ipc ids* ids, struct kern ipc perm* new int size) 
{ 


uid 七 euid; 
gid t egid; 
int id, err; 
/* 用 户 设置 的 


工 PC 对 象 的 上 限 ， 不 能 超过 系统 硬 上 限 


IPCMNI, 即 


32768%*/ 
if (size > IPCMNI) 
Size = IPCMNI; /* 如 果 系 统 中 已 经 存在 的 


工 PC 对 象 超过 了 个 数 上 限 ， 则 返回 失败 


六 
/ 

if (ids->in use >= size) 

return -ENOSPC; 

Spin lock init(&new->lock); 

new->deleted = 0; 

rcu read lock(); 

spin lock (gnew->lock); 

/* 通 过 


idr 管 理 ， 调 用 


idr_get_new 获 得 一 个 空闲 的 柳 位 


者 
err = idr get new(&ids->ipcs idr, new, &id); 
if (err) { 
spin unlock (&new->lock); 
rcu read unlock(); 
Pet STE 
} 
/* 系 统 当前 在 用 的 
工 PC 对 象 加 
1 
ids->in uset++; 
/* 设 置 创建 者 
ID 和 


owner ID*/ 
Current euid egid(g&euid, &egid); 
new->cuid = new->uid = euid; 
new->gid = new->cgid = egid; 
/*seq 的 值 自 加 ， 如 果 大 于 


Seq_max, 则 游 出 回 绕 至 


Og 
new->seq = ids->seqt++; 
if(ids->seq > ids->seq max) 
ids->seq = 0; 
new->id = ipc buildidl(id, new->seq); 
return id; 加 





















































前 面 提 到 ， 内 核 分 配 耻 C 对 象 标识 符 的 时 候 ， 使 用 的 并 不 是 最 小 可 用 算法 ， 其 使 用 的 算法 如 下 : 

















#define IPCMNI 32768 
#define SEQ MULTIPLIER (IPCMIN) 
static inline int ipc buildidl(int id, int seq) 


{ 
. 


return SEQ MULTIPLIER * seq + id; 




















上 面 公式 中 的 id 就 是 最 小 可 用 的 槽 位 ， 而 seq 是 开机 以 来 内 核 创 建 PC 对 象 的 流水 号 。 因 此 ， 返 回 的 卫 是 一 个 比较 大 的 值 。 仍 然 以 消息 队列 为 
例 ， 如 果 开 机 后 ， 消 息 队 列 为 空 ， 创 建 的 第 一 个 消息 队列 的 标识 符 必 然 为 0， 而 创建 的 第 二 个 消息 队列 和 第 三 个 消息 队列 的 值 则 为 : 















































32758 > 工 和 于 并 
32768 *2+ 六 
































根据 上 面 的 讨论 可 知 ， 卫 C 对 象 的 标识 符 了 虽然 是 通过 get 函 数 来 获得 的 ， 但 是 和 key 值 并 不 存在 永久 的 对 应 关系 ， 即 不 存在 公式 可 以 通过 key 
值 来 计算 出 标识 符 ID。 内 核 仅仅 是 关联 了 两 者 。 重 启 系统 之 后 ， 或 者 删除 了 PC 对 象 之 后 ， 根 据 相同 的 key 值 再 次 创建 ， 得 到 的 标识 符 D 很 可 能 # 



































不 相 


同 。 





内 核 














j 临 着 如 何 根据 IPC 对 象 的 标识 符 ID， 己 








速 地 找到 内 核 








Slot index = 标识 符 


ID % SEQ MULTIPLIER 








这 个 公式 透漏 出 了 
的 硬 上 限 为 IPCMNI, 

















FP 的 IPC 对 象 的 难题 ， 根 据 前 面 的 计算 公式 ， 不 难 做 到 : 












































个 问题 : 整个 系统 内 ， 每 一 种 耻 C 对 象 的 槽 位 





























E 实 了 这 一 点 ， 系 统 





限 ， 最 多 有 IPCMIN 个 档 位 。 在 ipc_addid 函 数 中 也 订 




















即 32768。 这 个 限制 就 决定 了 不 能 无 限制 地 创建 PC 对 象 。 


10.2 ”SystemV 消 息 队 列 


第 9 章 介绍 的 管道 和 FIFO 都 是 字 节 流 的 模型 ， 这 种 模型 不 存在 记录 边界 。 如 果 从 管道 里 面 读 出 100 
个 字 节 ， 你 无 法 确认 这 100 个 字 节 是 单 次 写 入 的 100 字 节 ， 还 是 分 10 次 每 次 10 字 节 写 入 的 ， 你 也 无 法 知 
晓 这 100 个 字 节 是 几 个 消息 。 管 道 或 FIFO 里 的 数据 如 何 解 读 ， 完 全 取决 于 写 入 进程 和 读 取 进程 之 间 的 约 


7 


契 。o 




















从 这 个 角度 上 讲 ，System V 消 息 队 列 和 POSIX 消 息 队 列 都 是 优 于 管道 和 FIFO 的 。 原 因 是 消息 队列 机 
制 中 ， 双 方 是 通过 消息 来 通信 的 ， 无 需 花 费 精 力 从 字 节 流 中 解析 出 完整 的 消息 。 























System V 消 息 队 列 比 管道 或 FIFO 优 越 的 第 二 个 地 方 在 于 每 条 消息 都 有 type 字 段 ， 消 息 的 读 取 进程 可 
以 通过 type 字 段 来 选择 自己 感 兴趣 的 消息 ， 也 可 以 根据 type 字 段 来 实现 按 消息 的 优先 级 进行 读 取 ， 而 不 
一 定 要 按照 消息 生成 的 顺序 来 依次 读 取 。 











内 核 为 每 一 个 System V 消 息 队 列 分 配 了 一 个 msg_queue 类 型 的 结构 体 ， 其 成 员 变 量 和 各 自 的 含义 如 
下 所 示 : 





struct msg queue 1 
struct kern ipc perm q perm; 
time t q stime; A* 自 一 次 


msgsnqd 的 时 间 


3 
time t q rtime; 7*: 三 = 次 


msgrcv 的 时 间 


WA 


time t q ctime; /* 属性 变化 时 间 
*/ 
unsigned long q cbytes; /* 队列 当前 字 节 总 数 
4 
unsigned long q_qgqnum; /* 队 列 当 前 消息 总 数 
给 人 
unsigned long q qbytes; /* 一 个 消息 队列 允许 的 最 大 字 节 数 
Ry 

















pid t q lspid; /上 上 一 个 调 


msgsnqd 的 进程 


ID*/ 
pid to Lepid; /二 二 站 牟 

















msgrcv 的 进程 


ID*/ 
struct list head q messages; 
struct list head q receivers; 
struct list head q senders; 
}; 





大 部 分 字段 的 含义 都 是 比较 好 理解 的 ， 后 面 遇 到 相关 内 容 的 时 候 会 详细 讲述 这 些 字 段 。 


10.2.1 创建 或 打开 一 个 消息 队列 









































消息 队列 的 创建 或 打开 是 由 msgget 函 数 来 完成 的 ， 成 功 后 ， 获 得 消息 队列 的 标识 符 ID， 函 数 接口 定义 如 下 : 














#include <sys/types.h> 

#include <sys/ipc.h> 

#include <sys/msg.h> 

int msgget (key t key, int msgflg); 
































区 





msgget 阔 数 中 两 个 参数 的 含义 前 面 已 经 讲述 过 了 ， 在 此 就 不 再 次 述 。 当 调用 成 功 时 ， 返 回 消息 队列 的 标识 符 ， 后 续 的 msgsnd、msgrev 和 
msgctl 函 数 都 通过 该 标识 符 来 操作 消息 队列 。 当 函数 调用 失败 时 ， 返 回 -1， 并 且 设 置 相应 的 errno。 常 见 的 errno 如 表 10-4 所 示 。 






























































表 10-4 ”msgget 出 错 情况 说 明 


errno 说 明 
ENOENT 对 应 key 值 的 消息 队列 不 存在 ， 并 且 没 有 设 定 IPC_CREAT 标志 位 
EACCES 存在 key 值 对 应 的 消息 队列 ， 但 是 没有 权限 打开 消息 队列 
EEXIST 存在 key 值 对 应 的 消息 队列 ， 但 是 同时 设置 了 IPC_CREAT 和 IPC_EXCL 标志 位 
ENOSPC 需要 创建 消息 队列 ， 但 是 超过 了 系统 允许 创建 消息 队列 的 上 上限。 上 限 值 为 MSGMNI 
ENOMEM 需要 创建 消息 队列 ， 但 是 系统 已 经 没有 足够 的 内 存 











关于 创建 消息 队列 ， 一 个 很 容易 想到 的 问题 是 :操作 系统 到 底 允 许 创建 多 少 个 消息 队列 ? 











表 10-4 中 提 到 ， 当 errno 等 于 ENOSPC 时 ， 表 示 创 建 的 消息 队列 超过 了 上 限 值 MSGMNI。 有 三 种 方法 可 以 查看 系统 消息 队列 个 数 的 上 限 ， 如 
下 所 示 。 











长 














方法 一 : 通过 procfs 查 看 。 














cat /proc/sys/kernel/msgmni 
3969 





方法 二 : 通过 sysctl 查 看 。 








Sysctl kernel.msgmni 
kernel.msgmni = 3969 








ipes = 可 -1 

= Messages Limits --------— 

max queues system wide = 3969 

max size of message (bytes) = 819 

default max size of queue es = 16384 














操作 系统 会 根据 系统 的 硬件 情况 〈 主 要 是 内 存 大 小 ) ， 计 算出 一 个 合理 的 上 限 值 ， 因 此 不 同 的 硬件 环境 下 ， 该 值 是 不 同 的 。 当 然 无 论 该 值 
设置 为 多 少 ， 内 核 都 存在 硬 上 限 IPCMNI (32768) 。 









































可 以 通过 如 下 的 手段 ， 修 改 msgmni 的 值 ， 从 而 允许 创建 更 多 的 消息 队列 。 





方法 一 : 通过 procfs 来 修改 。 





echo 20000 > /proc/sys/kernel/msgmni 
cat /proc/sys/kernel/msgmni 
20000 





方法 二 : 通过 sysctl-w 来 修改 。 





Sysctl -w kernel.msgmni=20000 











上 述 两 种 方法 都 是 立即 生效 ， 但 是 一 旦 系统 司 





tm 








启 ， 设 置 就 失去 了 。 要 想 确保 重启 后 依然 有 效 ， 需 要 将 配置 写 入 /etc/sysctl.conf。 









































kernel .msgmni=20000 





由 





注意 写 入 /etc/sysctlconf 并 不 会 立即 生效 ， 需 要 执行 sysctl-p 重 新 加 载 ， 改 变 方 能 生效 。 





10.2.2” 发 送 消 息 




































































获取 到 消息 队列 的 标识 符 之 后 ， 可 以 通过 调用 msgsnd 函 数 向 队列 中 插入 消息 。 内 核 会 负责 将 消息 维护 在 消息 队列 中 ， 等 待 男 外 的 进程 来 取 
走 消息 ， 从 而 完成 通信 的 全 过 程 。 














msgsnd 函 数 的 定义 如 下 : 





#include <sys/types.h> 

#include <sys/ipc.h> 

include <sys/msg.h> 

int msgsnd(int msqid, const void *msgp, size t msgsz, int msgflg); 








其 中 msqid 是 由 msgsget 返 回 的 标识 符 ID。 




































































参数 msgp 指 向 用 户 定义 的 缓冲 区 。 它 的 第 一 个 成 员 必 须 是 一 个 指定 消息 类 型 的 long 型 ， 后 面 跟着 消息 文本 的 内 容 。 通 常 其 定义 如 下 : 




















struct msgbuf { 
long mtype; /* 消 息 类 型 ， 必 须 大 于 


ee 
char mtext[1]; /* 消 息 体 ， 不 一 定 是 字符 数组 ， 可 以 是 任意 结构 





















































每 条 消息 只 能 存放 一 个 字符 ? 并 非 如 此 。 事 实 上 可 以 是 任意 结构 ，mtext 是 由 程序 员 定 义 的 结构 ， 其 长 度 和 内 容 都 是 由 程序 员 控制 的 ， 只 要 
发 送 方 和 接收 方 约定 好 即 可 。 比 如 可 以 将 结构 体 定义 如 下 : 














struct private buf 1{ 




















第 三 个 参数 msgsz 指 定 了 mtext 字 段 中 包含 的 字 节 数 。 消 息 队 列 单条 消息 的 大 小 是 有 上 限 的 ， 上 限 值 为 MSGMAX， 记 录 
在 /proc/sys/kernel/msgmax 中 : 




















cat /proc/sys/kernel/msgmax 
B192 

Sysctl1 kernel.msgmax 
kernel.msgmax = 8192 




















如 果 消 息 的 长 度 超过 了 MSGMAX， 那 么 msgsnd 函 数 返回 -1， 并 置 errno 为 EINVAL。 

















下 面 以 发 送 字符 串 消息 为 例 ， 介 绍 msgsnd 函 数 所 需 的 步 又 : 











1) 因为 glibc 并 未 定义 msgbuf 结 构 体 ， 因 此 首先 要 定义 msgbuf 结 构 体 。 





























2) 分 配 一 个 类 型 为 msgbuf， 长 度 足 以 容纳 字符 串 的 缓冲 区 mbuf。 





3) 将 message 的 内 容 拷贝 到 mbuf->mtext 中 去 。 























4) 在 mbuf->mtype 中 设置 消息 类 型 。 























5) 调用 msgsnd 发 送 消息 。 











6) 释放 mbuf。 














注意 两 点 ， 即 要 对 msgsnd 进 行 错误 检测 和 及 时 释放 mbuf， 以 防止 内 存 泄漏 。 




















最 后 一 个 参数 msgflg 是 一 组 标志 位 的 位 掩 码 ， 用 于 控制 msgsnd 的 行为 。 目 前 只 定义 了 IPC_NOWAIT 一 个 标志 位 。 


























IPC NOWAIT 表 示 执 行 一 个 无 阻塞 的 发 送 操作 。 当 没有 设置 PC NOWAIT 标 志 位 时 ， 如 果 消 息 队 列 满 了 ， 那 么 msgsnd 函 数 就 会 陷入 阻塞 ， 直 
到 队列 有 足够 的 空间 来 存放 这 条 消息 为 止 。 但 是 如 果 设 置 了 IPC NOWAIT 标 志 位 ， 那 么 msgsnd 函 数 就 不 会 陷入 阻塞 了 ， 而 是 立刻 返回 失败 ， 并 
置 errno 为 EAGAIN。 



















































































等 一 下 ， 这 里 好 像 提 到 了 消息 队列 满 。 什 么 情况 下 ， 消 息 队列 才能 被 称 为 是 满 的 ? 





王 何 一 个 消息 队列 ， 容 纳 的 字 节 数 是 有 上 限 的 。 这 个 上 限 值 为 MSGMNB， 该 值 被 记录 在 /proc/sys/kernel/msgmnb 中 : 











cat /proc/sys/kernel/msgmnb 
16384 

Sysctl1 kernel .msgmnb 
kernel.msgmnb = 16384 











内 核 中 消息 队列 对 应 的 数据 结构 msg_queue 中 维护 有 当前 字 节 数 、 当 前 消息 数 及 允许 的 最 大 字 节 数 等 信息 : 











struct msg queue { 


time t q stime; /* 最 后 调用 
msgsng 的 时 间 
A 

unsigned long q cbytes; /* 消 息 队 列 当前 字 节 的 总 数 
wy 

unsigned long q_qnum; /* 消 息 队 列 当前 消息 的 个 数 
yy 

unsigned long q qbytes; /* 消 息 队 列 允 许 的 消息 最 大 字 节 数 
a 

pid t q lspid; /* 最 后 调用 
msgsng 的 进程 


ID*/ 




















仿 查 消息 队列 是 否 满 的 逻辑 非常 简单 ， 内 核 判 断 能 否 立 刻 发 送 消 息 的 逻辑 如 下 : 




















if (msgsz + msq->q cbytes <= msq->q qbytes && 
1 + msq->q qnum <= msq->q qbytes) { 
break; 


} 











如 果 同 时 满足 以 下 两 个 条 件 ， 则 可 以 立即 发 送 消息 ， 无 须 阻塞 : 


I 











必 



































前 消息 的 字 节 数 msgsz) 加 上 消息 队列 当前 字 节 的 总 数 (msq->q_cbytes) 不 大 于 消息 队列 允许 的 最 大 字 节 数 (msq->q_qbytes) 。 









































-消息 队列 当前 消息 的 个 数 加 上 1 不 大 于 消息 队列 容许 的 最 大 字 节 数 Cmsq->q_qbytes) 。 





















































第 二 个 条 件 看 起 来 很 奇怪 的 ， 其 实 这 个 条 件 是 用 来 防范 空 消息 的 : 发 送 的 消息 只 有 mtype 字 段 ， 消 息 体 正文 mtext 都 是 空 的 。 








不 满足 上 述 两 个 条 件 的 话 ，msgsnd 函 数 会 根据 是 否 设置 了 IPC NOWAIT 标 志 位 来 决定 是 陷入 阻塞 还 是 立刻 返回 失败 。 






































如 果 因 消息 队列 满 而 陷入 阻塞 ，msgsnd 系 统 调用 则 可 能 会 被 信号 中 断 ， 当 这 种 情况 发 生 时 ，msgsnd 总 是 返回 EINTR 错 误 。 注意， 无 论 在 建立 
信号 处 理 函数 的 时 候 ， 是 否 设置 了 SA_RESTART 标 志 位 ，msgsnd 系 统 调用 都 不 会 自动 重启 。 






































加 





























无 论 是 否 经 过 阻塞 ， 只 要 没有 出 错 返 回 ， 调 用 msgsnd 都 需要 执行 下 面 的 操作 : 


























/* 将 最 后 调用 


msgsng 的 进程 


工 D 更 新 到 消息 队列 的 


9_1spig 成 员 变 量 中 


*/msq->q_lspid = task _tgiqd vnr (current);/* 将 最 后 调用 


mSgSsn9 的 时 间 更 新 到 消息 队列 的 


9_ stime 成 员 变 量 中 


4 
msq->q_stime = get_seconds () ; /* 如 果 有 进程 正在 等 待 该 消息 ， 则 就 地 消化 ， 无 须 进 入 消息 队列 


*/if (!pipelined send(msq, msg)) { 
/* 将 消息 链 入 消息 队列 的 链表 中 


list add tail (gmsg->m list, &msq->q messages); 
/* 更 新 消息 队列 当前 消息 的 字 节 数 
-yy 
msq->q_cbytes += msgsz; 
/* 更 新 消息 队列 当前 消息 的 总 数 
$s 
msq->q_qnumt++; 
/* 更 新 命名 空间 内 ， 所 有 消息 队列 的 总 字 节 数 和 消息 总 个 数 
a 


atomic add (msgsz, é&ns->msg bytes); 
atomic inc(&ns->msg hdrs); 












































pipelined_send 函 数 用 于 检测 是 否 有 进程 正在 等 待 该 消息 ， 如 果 有 的 话 ， 消 息 无 须 进 入 消息 队列 ， 而 是 “就 地 消化 "， 皆 大 欢喜 。 如 果 没 有 等 
等 该 消息 的 进程 ， 则 消息 就 不 得 不 进入 消息 队列 ， 等 竺 “有缘 人 "来 提取 。 
























































至 此 ，msgsnd 函 数 的 使 用 和 流程 基本 介绍 完毕 ， 如 果 执 行 成 功 ， 则 msgsnd 返 回 0， 如 果 失 败 ，msgsnd 则 返回 -1， 并 置 errno。 





























下 面 分 析 一 下 函数 的 返回 值 和 常见 错误 。msgsnd 函 数 不 同 于 文件 的 write 函数 ，write 函 数 操作 的 是 字 节 流 ， 存 在 部 分 成 功 的 概念 ， 所 以 成 功 
时 ， 返 回 的 是 写 入 的 字 节 个 数 ， 但 是 msgsnd 函 数 操作 的 是 封装 好 的 消息 ， 不 成 功 则 成 仁 ， 不 存在 部 分 成 功 的 情况 。 所 以 其 成 功 时 ，msgsnd 函 数 
0， 失 败 时 ，msgsnd 函 数 返回 -1， 并 且 设 置 errno。 常 见 的 出 错 情况 如 表 10-5 所 示 。 
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向 
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表 10-5 ”msgsnd 出 错 情况 说 明 


errno 说 明 

EACCESS 无 相应 权限 

EAGAIN 消息 队列 已 满 ， 并 且 设置 了 IPC_WAIT 标志 位 

EIDRM 消息 队列 已 经 从 系统 中 删除 ， 不 复 存 在 

EINTR msgsnd 被 信号 中 断 

EINVAL 标识 符 无 效 ，mtype 小 于 1，msgsz 小 于 0 或 大 于 上 限 MSGMAX 



































Ik 








的 出 错 情况 前 面 都 已 经 介绍 过 了 ， 除 了 EIDRM。 这 是 消息 队列 和 信号 量 的 共同 缺陷 。: 
可 能 已 经 删除 该 消息 队列 了 。 对 于 PC 对 象 ( 共 享 内 存 除外 〉 ， 内 核 并 没有 








一 个 进程 操作 消息 队列 时 ， 另 外 一 个 进程 
佳 护 引 用 计数 ， 删 除 行为 是 说 删 就 删 ， 于 是 msgsnd 调 用 就 会 收 到 



























































ASS 








下 






































EIDRM 的 错误 。 


























删除 消息 队列 是 
责 删 除 消息 队列 。 











个 编程 难点 ， 难 就 难 在 确定 删除 的 时 机 。 多 个 进 











程 需 引 











从 逻辑 上 确定 谁 是 最 后 一 个 访问 消息 队列 的 进 








程 ， 


然后 




















10.2.3 ”接收 消息 











有 发 送 就 要 有 接收 ， 没 有 接收 者 的 消息 是 没有 意义 的 。System V 消 息 队列 用 msgrcv 函 数 来 接收 消息 。 




















ssize t msgrcv(int msqid, void *msgp, size t msgsz, 
long msgtyp,int msgflg); 









































其 中 前 三 个 参数 与 msgsnd 的 含义 是 一 致 的 。msgrcv 调 用 进程 也 需要 定义 结构 体 ， 而 结构 体 的 定义 要 和 发 送 端的 定义 一 致 ， 并 且 第 一 个 字段 
必须 是 long 类 型 ， 代 码 如 下 所 示 : 














struct private buf {long mtype;struct pirate info { /* 定 义 你 需要 的 成 员 变 量 


.A 
}; 



























































对 于 有 具有 固定 长 度 的 消息 体 来 讲 ， 只 要 发 送 方 和 接收 方 的 结构 体 达 成 一 致 ， 就 不 会 存在 风险 。 但 是 如 果 消 息 体 是 变 长 的 ， 情 况 就 复杂 了 
点 。 因 为 不 能 预先 得 知 收 到 消息 体 的 长 度 ， 因 此 接收 端的 缓冲 区 要 足够 大 ， 防 止 消 息 队 列 中 的 消息 长 度 大 于 缓冲 区 的 大 小 。 




























































































Msgrcv 函 数 的 第 4 个 参数 msgtyp 是 消息 队列 的 精华 ， 提 取消 息 时 ， 可 以 选择 进程 感 兴趣 的 消息 类 型 。 正 是 基于 这 个 参数 ， 读 取消 息 的 顺序 才 
无 须 和 发 送 顺序 一 致 ， 进 而 可 以 演化 出 很 多 用 法 。msgtype 与 提取 消息 的 行为 关系 如 表 10-6 所 示 。 






























































表 10-6 ”msgtype 与 提取 消息 的 行为 





msgtype 动 作 
0 从 消息 队列 中 取出 第 一 条 消息 
msgtype 动 作 
有 MSG EXCEPT 标志 位 : 从 消息 队列 中 取出 mtype 等 于 msgtyp 的 第 一 条 消息 
~ 无 MSG_EXCEPT 标志 位 : 从 消息 队列 中 取出 mtype 不 等 于 msgtyp 的 第 一 条 消息 
一 0 从 消息 队列 中 取出 mtype 最 小 ， 并 且 值 小 于 或 等 于 msgtyp 绝对 值 的 第 一 条 消息 




















当 msgtyp 等 于 0 时 ， 行 为 模式 是 先入 先 出 的 模式 。 最 先进 入 消息 队列 的 消息 被 取出 。 




















当 msgtyp 小 于 0 时 ， 行 为 模式 是 优先 级 消息 队列 。mtype 的 值 越 低 ， 其 优先 级 越 高 ， 越 早 被 取出 。 
































当 msgtyp 的 值 大 于 0 时 ， 会 将 消息 队列 中 第 一 条 mtype 值 等 于 msgtyp 的 消息 取出 。 通 过 指定 不 同 的 msgtyp， 多 个 进程 可 以 在 同一 个 消息 队列 中 
挑选 各 自 感 兴趣 的 消息 。 一 种 常见 的 场景 是 各 个 进程 提取 和 自己 进程 DD 匹配 的 消息 。 



























































第 5 个 参数 是 可 选 标 志 位 。msgrev 函 数 有 3 个 可 选 标 志 位 。 
































-IPC_NOWAIT: 如 果 消 息 队 列 中 不 存在 满足 msgtyp 要 求 的 消息 ， 默 认 情 况 是 阻塞 等 待 ， 但 是 一 旦 设置 了 IPC_NOWAIT 标 志 位 ， 则 立即 返 
失败 ， 并 且 设 置 errno 为 ENOMSG。 








ed 















































-MSG_EXCEPT: 这 个 标志 位 是 Linux 特 有 的 ， 只 有 当 msgtyp 大 于 0 时 才 有 意义 ， 含 义 是 选择 mtype! =msgtyp 的 第 一 条 消息 。 










































































:MSG NOERROR: 前 面 也 提 到 过 ， 在 消息 体 变 长 的 情况 下 ， 可 能 事前 并 不 知道 消息 体 的 大 小 ， 尽 管 要 求 maxmsgsz 应 尽 可 能 地 大 ， 但 是 仍然 
存在 maxmsgsz 小 于 消息 体 大 小 的 可 能 。 如 果 发 生 这 种 情况 ， 默 认 情 况 是 返回 错误 E2BIG， 但 是 如 果 设 置 了 MSG _NOERROR 标 志 位 ， 情 况 就 不 同 
了 ， 此 时 会 将 消息 体 截断 并 返回 。 















































msgrcv 函 数 调用 成 功 时 ， 返 回 消息 体 的 大 小 ;失败 时 返回 -1， 并 且 设 置 errno。 大 部 分 出 错 情 况 和 msgsnd 函 数 类 似 ， 比 较 特 殊 的 错误 码 是 
E2BIG 和 ENOMSG， 刚 才 都 已 经 讨论 过 了 ， 这 里 不 再 歼 述 。 另 外 msgrcv 函 数 和 msgsnd 函 数 一 样 ， 如 果 被 信号 中 断 ， 则 不 会 重启 系统 调用 ， 哪 怕 安 
装 信号 时 设置 了 SA_RESTART 标 志 位 。 














































































































程 ， 要 么 以 阻塞 的 方式 调用 









































System V 消 息 队 列 存在 一 个 问题 ， 即 当 消 息 队列 中 有 消息 到 来 时 ， 无 法 通知 到 某 进 程 。 消 息 队 列 的 读 取 者 进 


msgrcv 函 数 ， 阻 塞 在 消息 队列 上 直到 消息 出 现 ， 要 么 以 非 阻 塞 (IPC_NOWAIT) 的 方式 调用 msgrcv 函 数 ， 失 败 返 回 ， 过 段 时 间 再 重 试 ， 除 此 以 外 


无 好 办 法 。 阻 塞 或 轮 询 ， 这 就 意味 着 一 个 进程 或 线程 不 得 不 无 所 事 事 ， 果 在 该 消息 队列 上 ， 这 给 编程 带 来 了 不 便 。 














































































































































































































epoll 等 1O 多 路 转 接 函数 ， 一 个 进程 就 能 同时 监控 多 个 文件 〈 或 者 多 个 消息 队列 )》， 提 





如 果 System V 消 息 队 列 是 文件 ， 能 支持 select、poll 和 
供 更 灵活 的 编程 模式 。 可 惜 的 是 ，System V 消 息 队列 并 非 文件 ， 不 支持 IO 多 路 转 接 函 数 。 第 11 章 中 可 以 看 到 POSIX 消 息 队 列 在 这 个 方面 所 做 的 


改进 。 






















































































10.2.4 


msgctl 函 数 可 以 控制 消息 队列 的 


控制 消息 队列 














到 
加 
所 











定义 如 下 : 





#include <sys/types.h> 
#include <sys/ipc.h> 
#include <sys/msg.h> 


int msgctl (int msqid, int cmd, struct msqid ds *buf); 





该 函数 提供 的 功能 取决 cmd 字 段 ，msgctl 支 持 的 操作 如 表 10-7 所 示 。 


1.IPC_STAT 


为 了 获取 消息 队列 的 属性 信息 或 设 
体 ， 其 大 部 分 字段 和 内 核 
该 结构 体 。 

















可 以 直接 使 























cmd 





IPC_ STAT 


IPC_SET 


IPC_RMID 

















机 

















的 msg_queue 结 构 















































i 属性， 必须 3 








个 








户 态 的 数据 结构 来 
本 相对 应 。 注 意 ，msqid_ds 结 构 体 9 


表 10-7 msgctl 支 持 的 命令 




















PP 包 含 下 再 


描 


获取 消息 队列 的 属性 信息 


删除 消息 队列 


述 消 息 队 列 的 





























村 























后 


的 成 员 变 量 。 在 编程 


设置 消息 队列 的 属性 


性 信息 ， 这 个 数据 结构 就 是 msqid_ds 结 构 


UD 











， 只 要 包含 了 对 应 的 头 文人 





F， 就 





#include <sys/msg.h> 


struct msqid ds { 


struct ipc perm msg perm; 


time t 


msgsng 的 时 间 


Wy 


time t 


InSGTCV 的 时 间 


本 人 


tima 七 


a 


unsigned long 


A 


msgqnum t 


A 
msglen t 


六 


msgsnq 的 进程 


ID */ 
Pid 七 


mSgrcv 的 进程 


ID*/ 
}; 


msg_stime; 


msg_rtime; 


msg_ctime; 


_msg cbytes; 


msg_qnum; 


msg_qbytes; 


msg_lspid; 


msg lrpid; 


/* Ownership and permissions */ 


/* 最 后 一 次 调用 


/* 最 后 一 次 调用 


/* 属 性 发 生变 化 的 时 间 


/* 消 息 队列 当前 的 字 节 总 数 


/* 消 息 队列 当前 消息 的 个 数 


/* 消 息 队列 允许 的 最 大 字 节 数 


/* 最 后 一 次 调用 


/* 最 后 一 次 调用 








几乎 全 部 的 字段 都 和 内 核 的 msg_queue 相 对 应 ， 而 
面 的 简单 代码 来 获取 到 消息 队列 的 属性 : 



















































































对 应 的 字段 的 含义 在 前 面 都 已 经 介绍 过 了 ， 此 处 不 再 次 述 。 在 使 用 时 ， 我 们 可 以 通过 下 





strutct msqid ds buf ; /* 注 意 包含 头 文件 
类 

msgct1l (mid, IPC_STAT, gbuf); /省 略 

error handle*/ 

printf(* 


Current # of messages in queue is %d\n” 


buf.msg_ qnum); 





2.IPC_SET 














消息 队列 开放 出 了 4 个 可 以 设置 的 属性 。 














‘msg perm.uid 


“msg perm.gid 


“msg perm.mode 


“msg qbytes 


















































设置 方法 一 般 首 先 调用 IPC_STAT 获 取 到 当前 的 设置 ， 然 后 修改 4 个 属性 中 的 某 个 或 某 几 个 
































发 性 ， 最 后 调用 IPC_SET， 代 码 如 下 所 示 : 





strutct msqid ds buf ， /* 注 意 包含 头 文件 
人 
msgct1l (mid, IPC_ STAT, gbuf); /六 省略 


error handle*/ 
buf.msg qbytes = NEW VALUE; 
msgctl (mid, IPC_ SET, gbuf); 





3.PC_RMID 


























IPC RMID 命 令 用 于 删除 与 标识 符 对 应 的 消息 队列 。 由 于 了 PC 对象 并 无 引用 计数 的 机 制 ， 因 此 只 要 有 权限 ， 可 以 说 册 





























删 。 消 息 队 列 中 的 所 有 消息 都 会 被 清除 ， 相 关 的 数据 结构 被 释放 ， 所 有 阻塞 的 msgsnd 函 数 和 msgrev 函 数 会 被 唤醒 ， 





就 删 ， 而 且 是 立刻 就 











返 








口 








EIDRM 错 误 。 


10.3 SystemV 信 号 量 


10.3.1 信号 量 概述 











System V 信 号 量 又 被 称 为 System V 信 号 量 集 
是 进程 之 间 传 递 消息 。 而 信号 量 的 作 










































































































































































， 事 实 上 信和 号 量 得 
j 是 为 了 同步 多 个 进程 的 操作 。 


























的 叫 法 更 符合 实际 情况 。 信 号 量 的 作用 和 消息 队列 不 太一 样 ， 


























消息 队列 的 作用 





















































































































































































































































































































































































































































































































































言 号 量 是 由 E.W.Dijkstra 为 互 斥 和 同步 的 高 级 管理 提出 的 概念 。 它 支持 两 种 原子 操作 ，wait 和 signal。wait 还 可 以 称 为 down、P 或 lock，signal 
还 可 以 称 为 pp、V、unlock 或 post。 其 作用 分 别 是 原子 地 增加 和 减少 信号 量 的 值 。 

一 般 来 说 ， 信 号 量 是 和 某 种 预先 定义 的 资源 相关 联 的 。 信 号 量 元 素 的 值 ， 表 示 与 之 关联 的 资源 的 个 数 。 内 核 会 负责 维护 信号 量 的 值 ， 并 确 
保 其 值 不 小 于 0。 

信号 量 上 支持 的 操作 有 : 

-将 信号 量 的 值 设 置 成 一 个 绝对 值 。 

在 信号 量 当 前 值 的 基础 上 加 上 一 个 数量 。 

在 信号 量 当 前 值 的 基础 上 减 去 一 个 数量 。 

等 待 信号 量 的 值 等 于 0。 

在 上 述 操 作 中 ， 后 两 个 可 能 会 陷入 阻塞 。 在 第 三 种 情况 中 ， 当 信和 号 量 的 当前 值 小 于 要 减 去 的 值 时 ， 操 作 会 陷入 阻塞 。 当 信和 号 量 的 值 不 小 于 
要 减 去 的 值 时 ， 内 核 会 唤醒 阻塞 进程 。 在 第 四 种 情况 中 ， 如 果 当 前 信号 量 的 值 不 为 0， 该 操作 会 陷入 阻塞 ， 直 到 信号 量 的 值 变 为 0 为 止 。 

这 些 操作 看 似 没 有 什么 意义 ， 但 是 一 旦 将 信号 量 和 某 种 资源 关联 起 来 ， 就 起 到 了 同步 使 用 某 种 资源 的 功效 ， 请 看 表 10-8。 

表 10-8 信号 量 与 资源 管理 
信号 量 操作 语 义 
将 信号 量 的 值 设 为 某 绝 对 值 初始 化 资源 的 个 数 为 某 绝 对 值 
在 信和 号 量 当 前 值 的 基础 上 加 上 一 个 数量 N 释放 N 个 资源 
在 信号 量 当 前 值 的 基础 上 减 去 一 个 数量 M 申请 M 个 资源 ， 可 能 因 资 源 不 够 而 陷入 阻塞 
等 待 信号 量 的 值 变 为 0 等 待 可 用 资源 个 数 变 为 0， 可 能 会 陷入 阻塞 

使 用 最 广泛 的 信号 量 是 二 值 信 号 量 (binary semaphore〉。 对 于 这 种 信号 量 而 言 ， 它 只 有 两 种 合法 值 ，0 和 1， 对 应 一 个 可 用 的 资源 。 若 当前 
有 资源 可 用 ， 则 与 之 对 应 的 二 值 信号 量 的 值 为 1， 关 资源 已 被 占用 ， 则 与 之 对 应 的 二 值 信号 量 的 值 为 0。 当 进程 申请 资源 时 ， 如 果 当 前 信和 号 量 的 
值 为 0， 那 么 进程 会 陷入 阻塞 ， 直 到 有 其 他 进程 释放 资源 ， 将 信号 量 的 值 加 1 才能 被 唤醒 。 

从 这 个 角度 看 ， 二 值 信 号 量 和 互 斥 量 所 起 的 作用 非常 类 似 。 那 信号 量 和 互 斥 量 有 何不 同 之 处 呢 ? 

互 斥 量 (mutex) 是 用 来 保护 临界 区 的 ， 所 谓 临界 区 ， 是 指 同一 时 间 只 能 容许 一 个 进程 进入 。 而 信号 量 (semaphore〉 是 用 来 管理 资源 的 ， 资 
源 的 个 数 不 一 定 是 1， 可 能 同时 存在 多 个 一 模 一 样 的 资源 ， 因 此 容许 多 个 进程 同时 使 用 资源 。 

有 个 很 有 意思 的 卫生 间 理 论 可 以 用 来 前 述 互 斥 量 和 信和 号 量 的 区 别 。 互 斥 量 好 比 是 一 把 卫生 间 的 钥匙 ， 卫 生 间 只 有 一 个 ， 钼 匙 也 只 有 一 把 。 
需要 使 用 卫生 间 时 ， 首 先 要 去 钥匙 存放 处 取 走 钥匙 ， 当 使 用 完了 卫生间 时 ， 要 将 钥匙 归还 到 钥匙 存放 处 。 如 果 某 人 需要 使 用 了 卫生间， 发 现 钥匙 存 
放 处 没有 钥匙 ， 那 么 他 就 需要 等 待 ， 直 到 卫生 间 的 当前 使 用 者 将 钥匙 归还 。 

假设 后 来 买 J 





























数 ， 最 初 有 8 把 钥 是 放 在 钥匙 存放 处 。 当 同时 使 用 
个 人 和 第 10 个 人 要 使 用 卫生 间 时 ， 发 现 已 经 没有 钥匙 了 




































































套 豪 宅 ， 家 里 有 8 个 一 模 一 样 的 卫生 


卫 牛 间 





间 和 8 把 通用 的 钥 是 。 这 时 信号 量 就 横 空 出 世 了 。 














的 值 的 含义 是 当前 可 用 的 钥匙 


Ee 
于 二 

















的 人 数 小 于 或 等 于 8 时 ， 大 家 都 可 以 拿 到 一 把 钥匙 ， 各 自 使 


























j 各 自 的 卫生 间 。 但 是 到 第 9 














， 所 以 他 们 就 不 得 不 等 待 了 。 











面 的 讨论 看 ， 信 和 号 














信号 量 解决 的 问题 是 不 同 的 。 





互 斥 量 的 关键 在 于 互 斥 、 





互 斥 量 的 一 个 扩展 ， 由 于 资源 数 














排 它 ， 同 














锁 进 程 ， 代 码 如 下 所 示 : 




















增多 ， 增 强 了 并 行 度 。 但 是 这 仅仅 是 一 个 方面 。 

















互 斥 量 和 


要 的 区 别 是 ， 





jm 























时 间 只 人 允许 一 个 线程 访问 临界 区 。 这 种 严格 的 互 斥 ， 决 定 了 解 铃 ; 


还 须 系 铃 人 ， 即 加 锁 进程 必然 也 是 解 





2 
pthread mutex lock() 
/* 安 全 地 访问 临界 区 


wy 
pthread mutex unlock(); 


要 


进程 


pthread mutex lock() 


/* 安 全 地 访问 临界 区 


Pthread mutex unlock(); 





而 信号 
































生产 者 进程 只 负责 增加 信号 量 的 值 ， 而 消 





量 的 关键 在 于 资源 的 多 少 和 有 无 。 申 请 资源 的 进程 不 一 定 要 释放 资源 ， 


























费 者 进程 只 负 


责 减 少 


信号 


的 值 。 























信和 号 量 同样 可 以 用 于 生产 者 -消费 者 的 场景 。 在 这 种 场景 下 



































彼此 之 间 通 过 








信号 量 的 值 来 同步 。 





生产 者 进程 


Post 


消费 者 


wait 








和 二 值 信号 量 相 比 ，System V 信 号 量 在 两 个 维度 上 都 做 了 扩展 。 











第 一 ， 资 源 的 数 





可 以 是 多 个 。 








第 二 ， 人 允许 同时 管理 多 种 资源 ， 由 多 个 计数 信号 量 组 成 的 








资源 个 数 超过 1 个 的 信号 量 称 为 计数 信 




















个 集 合 条 


童 号 量 (counting semaphore) 。 








你 为 计数 信和 号 
FP 几 种 资源 。 





总 数 是 5， 第 二 种 资源 的 总 数 是 10。 在 使 用 过 程 中 可 选择 申请 哪 种 资源 或 
坦率 来 讲 ，System V 信 号 量 有 点 设计 过 度 ， 第 二 种 所 


























口 过 于 复杂 ， 使 








不 便 。 




















展 并 无 必要 ， 同 











时 操作 集合 中 的 多 个 信号 量 的 能 


量 集 ， 每 个 计数 信号 量 管理 一 种 资源 。 比 如 第 一 种 资源 的 





是 多 余 的 ， 而 这 种 扩展 导致 了 编程 





10.3.2 ”创建 或 打开 信和 号 量 








创建 或 打开 信号 量 的 函数 为 semget， 其 接口 定义 如 下 : 











#include <sys/types.h> 

#include <sys/ipc.h> 

#include <sys/sem.h> 

int Semget (key t key, int nsems, int semflg); 




















tt 











这 个 接口 比较 简单 ， 第 二 个 参数 nsems 表 示 信 号 量 集中 信号 量 的 个 数 。 换 句 话说 ， 就 是 要 控制 几 种 资源 。 大 部 分 情况 下 只 控制 一 种 。 如 果 





























非 创 建 信号 量 ， 仅 仅 是 访问 已 经 存在 的 信号 量 集 ， 可 以 将 nsems 指 定 为 0。 
































semflg 支 持 多 种 标志 位 。 目 前 支持 PC_CREAT 和 IPC _EXCL 标 志 位 ， 其 含义 不 再 歼 


























在 创建 信号 量 时 ， 需 要 考虑 的 问题 是 系统 限制 。 系 统 的 限制 可 以 分 成 三 个 层面 。 














:系统 容许 的 信号 量 集 的 上 限 : SEMMNI 














中 信号 量 的 上 限 : SEMMSL 


Zl 
由 
lm 
I 
uy 





:系统 容许 的 信号 量 的 上 限 : SEMMNS 




















首先 介绍 下 对 于 每 种 限制 ， 系 统 提 供 的 硬 上 限 ， 如 表 10-9 所 示 。 























表 10-9 信号 量 的 系统 硬 上 限 


限 制 最 大 值 
SEMMNI 系统 容许 创建 的 信号 量 集 的 上 限 32768 (IPCMNI) 
SEMMSL 一 个 信号 量 集 里 信号 量 的 最 大 数量 65536 


SEMMNS 系统 中 所 有 信号 量 集 里 的 信号 量 总 数 的 上 限 2147483647 (INT MAX) 














其 中 SEMMSL 的 硬 上 限 是 65536， 原 因 是 semop 函 数 中 定义 了 sembuf 结 构 体 来 操作 信号 量 集中 的 信号 量 ， 代 码 如 下 所 示 : 























struct sembuf{ 
unsigned short sem num; 

















sembuf 结 构 体 中 的 成 员 变 量 sem_num 用 来 指定 修改 集合 中 的 哪个 信号 量 。 其 数据 类 型 是 无 符号 短 整 型 (unsigned short) 。 我 们 固然 可 以 一 意 
孤 行 地 将 SEMMSL 的 值 设置 为 大 于 65536 的 数值 ， 但 是 后 续 将 无 法 通过 semop 来 操作 它 ， 因 此 它 也 就 失去 了 存在 的 意义 。 因 此 集合 中 信号 量 个 数 
的 硬 上 限 值 为 65536。 













































































之 所 以 SEMMNS 的 上 限 值 为 INT MAX， 原因 是 内 核 使 用 了 int 型 来 存储 该 值 ， 代 码 如 下 所 示 : 

















struct ipc namespace{ 

i Sem ctls[4];... 
} 
#define sc semmsl sem ctls[0 
#define sc_semmns sem ctls[1 
#define sc semopm sem ctls[2 
#define sc semmni sem ctls[3 


] 
] 
] 
] 














在 硬 上 限 范 围 内 ， 可 以 通过 sysctl 来 设置 软 上 限 。 

















cat /proc/sys/kernel/sem 

32000 1024000000 500 32000 

sysctl] kernel.sem 

kernel.sem = 32000 1024000000 500 32000 








其 中 4 个 值 的 含义 如 图 10-7 所 示 。 





/proc/sys/Kkernel/sem 





32000 1024000000 32000 


图 10-7 信号 量 相 关 的 控制 选项 的 含义 






































第 三 个 值 (SEMOPM) 的 含义 将 放 到 后 面 再 介绍 。 可 以 通过 sysctl-w 或 修改 /etc/sysctl.conf 来 设置 控制 参数 。 注 意 不 要 超过 硬 上 限 。 
























































如 果 超 过 系统 限制 时 ， 返 回 的 错误 码 见 表 10-10。 











表 10-10 信和 号 量 超过 系统 限制 相关 的 错误 码 


因 信号 量 集 的 个 数 达到 上 限 而 失败 ENOSPC 
因 信号 量 的 个 数 达到 上 限 而 失败 ENOSPC 
因 单 个 信号 量 集中 信号 量 的 个 数 超过 上 限 而 失败 EINVAL 


在 System V 信 号 量 的 接口 设计 中 ， 存 在 一 个 致命 的 缺陷 ， 即 创建 信号 量 集 和 初始 化 集合 中 的 信号 量 是 两 个 独立 的 操作 ， 而 非 一 个 原子 操作 ， 
标准 并 未 要 求 创 建 信号 量 集 时 ， 将 信号 量 的 值 初始 化 为 0。 当 然 ， 在 Linux 系 统 上 ，semget 函 数 返 回 的 信号 量 实际 上 会 被 初始 化 为 0。 



























































民 瑟 旦 












































但 是 很 多 情况 下 ， 信 和 号 量 的 初始 值 并 不 希望 为 0， 因 此 需要 额外 调用 一 次 semct 的 SETVAL 命 令 来 设置 初始 值 。 由 于 创建 和 初始 化 之 间 存 在 一 
个 时 间 窗 口 ， 因 此 可 能 会 出 现 竞 态 条 件 (race condition) ， 见 表 10-11。 





























表 10-11 创建 和 初始 化 分 开 ， 产 生 竞 态 条 件 的 一 种 情况 
进 程 1 进 程 2 
调用 semget 函数 创建 信号 量 集 调用 semget 函数 获取 信号 量 集 的 标识 特 ID 


调用 semop 修改 信号 量 的 值 
调用 semetl 的 SETVAL 命令 初始 化 


















































在 表 10-11 这 种 时 序 条 件 下 ， 信 号 量 的 值 尚未 初始 化 就 被 进程 2 通过 semop 函 数 修改 了 。 而 后 面 进程 1 的 初始 化 命令 又 会 覆盖 进程 2 所 做 的 更 
改 。 

















W.Richard Stevens 在 名 著 《Unix 网 络 编程 卷 2:， 进程 间 通 信 》 中 给 出 了 如 下 思路 来 解决 这 个 























EH 
上 














内 核 与 信号 量 集 相 关 的 数据 结构 sem_array 中 有 一 个 成 员 变 量 sem otime， 如 下 所 示 : 








struct sem array { 


time £ sem otime; /* 上 次 执行 


Semop 的 时 间 





7 








信号 量 集 被 创建 的 时 候 ，sem_otime 被 初始 化 成 0， 在 后 续 执 行 semop 操 作 的 时 候 ， 才 会 对 sem_otime 的 值 进行 修改 。 因 此 可 以 利用 这 个 属性 来 
消除 竞争 。 即 第 二 个 进程 要 等 到 创建 信号 量 的 进程 执行 过 一 次 修改 信号 量 值 的 semop 操 作 后 《通过 判断 sem_otime 的 值 是 否 为 0) ， 才 开始 正常 的 


日 止 吊 让 








































































































《LinuxwUnix 系 统 编 程 手册 《〈 下 册 ) 》 中 也 采用 了 这 个 思路 解决 了 竞争 问题 ， 并 给 出 了 示例 代码 。 但 其 示例 代码 适用 范围 比较 狭 
于 将 信号 量 初始 化 为 0 这 种 场景 。 稍 加 改造 ， 就 可 以 适用 于 将 信号 量 初始 化 为 任意 值 的 场景 。 有 具体 做 法 如 图 10-8 所 示 。 




























































































POSIX 信 号 量 作为 后 来 者 ， 注 意 到 了 System V 信 号 量 的 这 个 弊端 ， 于 是 将 创建 和 初始 化 由 一 个 接口 来 完成 。 详 情 可 阅读 第 11 章 。 












































10.3.3 ”操作 信号 量 








semop 函 数 负 责 修改 集合 中 一 个 或 多 个 信号 量 的 值 ， 其 定义 如 下 : 





#include <sys/types.h> 

#include <sys/ipc.h> 

#include <sys/sem.h> 

int Semop (int semid, struct sembuf *sops, unsigned nsops); 





带 IPC_CREAT 和 IPC_EXCL 
标志 创建 信号 量 





EEXIST 






调用 se et 的 SETV AL 命令 调用 semctl 函 数 的 IPC_STAT 
初始 化 信号 的 值 为 0 操作 ， 获 取 sem_otime 


执行 一 次 semop 操 作 
将 信号 量 的 值 设 为 初始 值 


sleep(]) 





正常 使 用 信号 量 集 
图 10-8 ”信号 量 的 创建 和 初始 化 流程 图 


函数 的 第 一 个 参数 是 通过 semsget 获 取 到 的 信号 量 的 标识 符 ID。 第 二 个 参数 是 sembuf 类 型 的 指针 。sembuf 结 构 体 定 义 在 sys/sem.h 头 文件 中 。 一 
般 来 说 ， 该 结构 体 至 少 包含 以 下 三 个 成 员 变量 : 











struct sembuf { 
unsigned short int sem num; 
Short sem op; 
short sem flg; 

有 















































成 员 变 量 sem_num 解 决 的 是 操作 哪个 信号 量 的 问题 。 因 为 信号 量 集中 可 能 存在 多 个 信号 量 ， 需 要 用 这 个 参数 来 告知 semop 函 数 要 操作 的 是 哪 
个 信号 量 ，0 表 示 第 一 个 信号 量 ，1 表 示 第 二 个 信号 量 ， 依 此 类 推 ， 最 大 为 nsems-1， 即 不 得 超过 集合 中 信号 量 的 个 数 。 如 果 sem_num 的 值 小 于 0， 


或 者 大 于 等 于 集合 中 信号 量 的 个 数 ，semop 调 用 则 会 返回 失败 ， 并 置 errno 为 EFBIG。 














































































































一 般 来 讲 ， 不 建议 采用 如 下 方法 来 初始 化 sembuf: 





struct sembuf myopsbuf = {1,-1,0} 

















因为 考虑 到 可 移植 性 ， 我 们 并 没有 十 足 的 把 握 可 以 确定 sembuf 结 构 体 中 成 员 变 量 的 顺序 和 上 面 定义 中 给 出 的 顺序 是 严格 一 致 的 。( 不 过 
Linux 的 定义 就 是 上 面 给 出 的 定义 ， 若 不 考虑 可 移植 性 ， 可 以 放心 采用 上 面 的 方法 。) 
















































































semop 函 数 的 典型 用 法 如 下 所 示 : 

















struct sembuf myopsbuf[3] : 


myopsbuf[0] .sem num = 0; /* 操 作 信 号 量 集中 的 第 


0 个 信号 量 


二 
myopsbuf [0] .sem op = -1; /* 信 号 量 


0 的 值 减 去 


工 ， 即 申请 


1 个 资源 


%¥ 
myopsbuf [0] 
myopsbuf[1] 


.Sem flg 
.Sem num 


; /* 操 作 信 号 量 集中 的 第 


1 个 信号 量 


wf 


myopsbuf[1] .sem op = /* 信 号 量 


1 的 值 加 上 


oa 
myopsbuf [1] 
myopsbuf [2] 


.Sem flg 
.Sem num 


; /* 操 作 信 号 量 集中 的 第 


2 个 信号 量 


大 


myopsbuf [2] .sem op = 0; /* 等 待 第 


2 个 信号 量 的 值 变 为 


Ow 

myopsbuf[2] .sem flg = 0; 
if (semop (semid,myopsbuf, 3) 
{ 


/*error handler here*/ 



















































































































































































semop 函 数 每 次 会 操作 一 组 信号 量 ， 每 个 信号 量 由 一 个 sembuf 来 表示 ， 修 改 一 个 信号 量 最 好 也 将 其 定义 成 struct sembuf ops[1] 这 样 的 数 
组 ，semop 函 数 的 第 三 个 参数 表示 要 操作 的 信号 量 的 个 数 。 
如 果 调 用 semop 函 数 同 时 操作 多 个 信号 量 ， 要 被 原子 地 执行 ， 要 么 内 核 完 成 所 有 操作 ， 要 么 内 核 什 么 也 不 做 。 
尽管 信号 量 集 支 持 同 时 操作 多 个 信号 量 ， 但 事实 上 这 种 场景 是 非常 罕见 的 。 大 多 数 情况 下 ， 只 会 操作 集合 中 的 一 个 信号 量 。 更 常见 的 是 使 
用 如 下 方式 。 
struct sembuf myopsbuf[1] : 
myopsbuf [0] .sem num = 0; 
myopsbuf[0] .sem op = -1;  /* 信 号 量 
0 的 值 减 去 
A 
myopsbuf[0] .sem flg= 0 
if (semop (semid,myopsbuf,1) == -1) 
sembuf 中 的 sem_op 可 以 是 正 值 ， 也 可 以 是 负 值 ， 还 可 以 是 9。 介绍 其 含义 之 前 ， 首 先 来 介绍 几 个 相关 的 变量 。 





























信号 量 的 当前 值 ， 表 示 当 了 的 资 





‘semval: 本 可 





‘semzcnt: 











资源 个 数 ， 永 远 非 负 。 


正在 等 待 信号 量 的 值 变 成 0 的 进程 个 数 。 











正在 等 待 信号 量 的 值 大 于 当 





前 值 的 进程 





个 数 。 





‘semncnt: 


根据 sem op 的 值 和 sem flg 值 ，semop 函 数 的 行为 模式 如 表 10-12 所 示 。 








sem_op 
二 0 
一 0 
sem_op 
绝 
<0 
六 


单 次 semop 调 








表 10-12 semop 的 含义 


含义 


用 于 释放 资源 。 


将 对 应 信 : 
其 要 求 ， 则 将 


用 于 等 待 信 


如 果 当 前 semval 等 
semval 不 等 


口 如 果 指 


口 如 果 未 


本 semval 的 值 加 上 sem_op 的 值 。 如 有 其 他 进程 等 待 资 源 且 增加 后 的 信号 量 值 满 


号 量 值 变 成 0。 
， 则 立即 返回 成 功 。 
ee 


江 


定 了 IPC_NOWAIT， 则 立即 返回 失败 ，errno 为 EAGAIN. 


含义 


省 定 IPC_NOWAIT， 则 陷入 阻塞 。semzcnt 的 值 加 1。 


一 般 有 三 种 情况 可 以 从 阻塞 中 醒 来 : 


有 信号 


- 量 值 变 成 了 0， 则 成 功 返 回 ，semzent 的 个 数 减 少 1 个。 


若 信号 量 被 删除 ， 则 返回 失败 ， 并 普 errno 为 ERMID。 
画 若 semop 系统 调用 被 信号 中 断 ， 则 返回 失败 ， 并 置 errno 为 EINTR ，semzcnt 的 个 数 减少 1 个 。 
用 于 申请 资源 。 
车 信号 量 的 值 不 小 于 sem_op 的 绝对 值 ， 则 表示 资源 足够 可 用 ， 信 号 量 的 值 semval 减 掉 sem op 的 


对 值 ， 


并 成 功 返 回 。 


信和 号 量 的 值 小 于 sem_op 的 绝对 值 时 : 
口 如 果 指 定 了 IPC_NOWAIT， 则 立即 返回 失败 ，errno 为 EAGAIN。 
口 如 果 未 指定 IFC_NOWAIT， 则 陷入 阻塞 ，semncnt 的 值 加 1。 


一 般 有 


三 种 情况 可 以 从 阻塞 中 醒 来 : 


~ 有 信号 量 的 值 变 成 了 不 小 于 sem_op 的 绝对 值 ， 则 成 功 返 回 。 
若 信号 量 被 删除 ， 则 返回 失败 ，errno 为 ERMID。 
符 semop 系统 调用 被 信号 中 断 ， 则 返回 失败 ， 并 第 errno 为 EINTR 。 





: 单 次 semop 调 用 能 够 操作 的 








秆 于 semop 操 作 ， 也 存在 如 下 系统 限制 : 


言 写 量 的 最 大 值 : SEMOPM 


上 限 : SEMVMX 





























能 够 操作 的 信号 量 的 最 大 个 数 记录 在 procfs 中 : 











Sysctl kernel.sem 
kernel.sem = 32000 1024000000 


500 32000 





如 果 nsops 的 值 超过 了 SEMOPM， 则 semop 函 数 返回 -1， 并 置 errno 为 E2BIG。 


























1， 
通 
言 ， 不 外 平 











除 此 之 外 ， 信 号 量 的 值 也 是 有 上 限 的 ， 最 大 值 为 32767。 若 semop 的 增加 操作 导致 信号 量 的 值 超过 了 其 上 限 SEMVMX， 那 么 semop 函 数 返 回 - 
并 置 errno 为 ERANGE。 


















































过 上 面 的 讨论 ， 不 难看 出 semop 接 口 复杂 难 用 。 成 熟 的 项 目 都 会 将 semop 函 数 封装 起 来 ， 提 供 更 好 用 、 语 义 更 简单 的 接口 。 对 于 编程 者 而 
1 请 资源 (wait) 和 释放 资源 (post) ， 可 将 接口 进行 如 下 封装 : 























int semaphore wait (int semid, int index) 
{struct sembuf operations[1];ope 


. 


Fations [0] .sem num = index;operations[0] .sem op = -1;operations [0] .sem flg = SEM UNDO;return semop (semid, operations, 1); 


int semaphore post (int semid, int index) 
{struct sembuf operations[1];ope 


rations[0] .sem num = index;operations[0] .sem op = 1;operations [0] .sem flg = SEM UNDO;return semop (semid, operations, 1); 











蕊 


而 


使 
































时 ， 如 果 需 要 等 待 资源 ， 就 调用 semaphore_wait 函 数 : 








semaphore wait (Semid,0) 





释放 资源 的 时 候 ， 就 调用 semaphore_post 函 数 : 








semaphore post (semid,0) 














注意 ， 上 面 的 封装 仅仅 是 做 一 个 简单 的 示意 ， 很 多 问题 并 未 考虑 (比如 未 考虑 系统 调 月 





昌 被 信号 












































在 项 目 中 一 般 作为 底层 基础 库 ， 真 正 封装 的 时 候 要 小 心 谨慎 ， 考 虑 各 种 场景 。 



































封装 示例 中 使 用 了 SEM_UNDO 标 志 位 ， 其 含义 见 10.3.4 节 。 


FP 断 ， 收 到 EINTR 错 误 码 的 场景 ) ， 这 些 封装 


10.3.4 信和 号 量 撤销 值 





















































使 用 信号 量 存在 这 样 一 种 风险 ， 即 进程 申请 了 资源 ， 修 改 了 信号 量 的 值 ， 却 没 来 得 及 释放 资源 就 异常 退出 了 。 异 常 退出 的 进程 


























































































































.资源 带 进 
了 坟墓 ， 而 其 他 进程 却 在 苦 苦 等 待 其 释放 资源 。 这 就 意味 着 资源 泄漏 ， 即 该 进程 申请 的 资源 再 也 无 法 给 其 他 进程 使 用 了 。 对 于 二 值 信号 量 来 
说 ， 资 源 泄漏 的 危害 尤其 大 。 





















































I 














和 





Ht 





为 了 避免 因 这 个 问题 而 陷入 不 可 收拾 的 境地 ， 内 核 提 供 了 一 种 解决 方案 ， 即 内 核 会 负责 记 住 进程 对 信号 量 施 加 的 影响 ， 当 ; 
负 


退出 的 时 
候 ， 内 核 负 责 撤销 该 进程 对 信号 量 施加 的 影响 。 
































jsemop 函 数 时 ， 可 以 通过 如 下 方法 设置 SEM_UNDO 标 志 位 。 




















Pa 
可 




















struct sembuf myopsbuf[1]; 
myopsbuf [0] .sem num = 0; 
myopsbuf[0] .sem op = -1; /* 信 号 量 


0 的 值 减 去 


Tw 
myopsbuf [0] .sem flg |= SEM UNDO ， 
semop (semid,myopsbuf,1); 



































内 核 并 不 会 为 所 有 带 SEM_UNDO 标 志 位 的 semop 操 作 都 保存 一 笔记 录 ， 内 核 维护 了 一 个 名 为 semadj 的 变量 ， 该 变量 记录 了 
上 使 用 SEM_UNDO 操 作 所 做 的 调整 总 和 。 








个 进程 在 信号 

















带 SEM_UNDO 标 志 位 的 semop 对 semadj 的 影响 如 表 10-13 所 示 。 





表 10-13 ”semadj 与 sem _ op 的 关系 


sem_op semadj 的 调整 
semadj 王 semadj 一 sen op 


semadj 王 semadj 十 abs(sem_ op) 





Lk 


器» 


进程 退出 时 ， 会 将 信号 量 的 当前 值 加 上 这 个 semadj， 来 撤销 进程 对 信号 量 的 影响 。 












































请 资源 和 释放 资源 时 ，SEM_UNDO 标 志 位 要 成 对 地 出 现 。 切 不 可 只 在 申请 资源 的 时 候 使 用 SEM_UNDO， 或 者 只 在 释放 资源 的 时 候 使 用 


SEM_UNDO， 这 都 会 造成 semadj 失 准 ， 不 能 正确 地 反映 进程 对 信号 量 施 加 的 影响 。 

























































































I 








使 用 semctl 的 SETVAL 或 SETALL 命 令 重新 设置 信号 量 的 值 时 ， 所 有 使 用 这 个 信号 量 的 进程 中 的 semadj 值 都 会 被 重 置 为 0。 因 
SETALL 相 当 于 开启 了 上 帝 模 式 ， 强 行将 信号 量 的 值 设 定 为 某 个 值 了 。 



































为 SETVAIL 或 






























































SEM_UNDO 也 不 是 包 治 百 病 的 良药 。 信 号 量 是 用 来 管理 资源 的 ， 本 身 并 无 实际 含义 ， 如 果 进 程 异常 退出 ， 而 资源 并 没有 进入 一 个 合理 且 稳 





















































2 


定 的 状态 ， 单 单调 整 信号 量 的 值 并 不 一 定 能 使 应 用 恢复 到 一 个 稳定 一 致 的 状态 。 


















































除 此 以 外 ， 在 某 些 情况 下 ， 进 程 终止 时 ， 也 无 法 严格 地 按照 进程 的 semadj 来 调整 信号 量 的 值 ， 考 虑 如 下 情景 : 





1) 信号 量 的 初始 值 是 0。 





























2) A 进 程 将 信号 量 增加 2， 并 且 设 置 了 SEM_UNDO 标 志 位 。 

















3) B 进 程 将 信号 量 减 去 1， 此 时 信号 量 的 值 变 为 1。 














4) A 进 程 退出 。 












































按照 逻辑 ， 应 该 将 当前 信号 量 的 值 减 去 2。 但 是 由 于 当前 信号 量 的 值 是 1， 不 可 能 减 去 2， 那 该 怎么 办 呢 。 对 于 此 困 
可 能 地 减 小 信号 量 的 值 。 对 于 本 例 ， 就 是 将 信号 量 的 值 减少 为 0。 

















境 ，Linux 采 用 的 办 法 是 尽 



























































上 面 的 情况 是 向 下 浇 出 ， 与 之 对 应 的 情况 是 向 上 溢出 。 即 如 果 加 上 撤销 量 ， 信 号 量 的 值 超 过 了 上 限 SEMVMX， 内 核 会 将 信号 量 的 值 调整 为 








SEMVMX。 这 部 分 逻辑 体现 在 ipc/sem.c 中 的 exit_sem 函 数 中 ; 








for (i = 0; i < sma->sem nsems; i++) { 
struct Sem 大 semaphore = &sma->sem basel[il]; 
if (un->semadj[i]) { 
/* 信 号 量 的 值 加 上 退出 进程 的 对 应 的 撤销 值 


ba 
semaphore->semval += un->semadj [i];/* 向 下 溢出 ， 则 置 为 
Oy 
if (semaphore->semval < 0) 
semaphore->semval = 0; 
/* 向 上 溢出 ， 则 置 为 
SEMVMX*/ 


if (semaphore->semval > SEMVMX) 
semaphore->semval = SEMVMX; 
semaphore->sempid = task tgid vnr(current); 














一 般 来 讲 ，SEM_UNDO 标 志 位 多 用 于 二 值 信号 量 。 











10.3.$ ”控制 信号 量 


控制 信号 量 的 函数 为 semctl 函 数 ， 其 定义 如 下 : 





#include <sys/types.h> 

#include <sys/ipc.h> 

#include <sys/sem.h> 

int semctl (int semid, int semnum, int cmd,/* union semun arg*/); 





某 些 特定 的 操作 需要 第 四 个 参数 ， 第 四 个 参数 是 联合 体 ， 很 不 笠 的 是 这 个 联合 体 需要 程序 员 自 己 
定义 ， 代 码 如 下 所 示 : 





union semun { 
Ei val; 
struct semid ds *buf; 
unsigned short *array; 
struct seminfo * buf; /*Linux 特 有 的 





根据 第 三 个 参数 cmd 值 的 不 同 ，semctl 支 持 以 下 命 


1.IPC RMID 


semctl 函数 的 第 二 个 参数 被 忽略 。 和 消息 队列 的 删除 一 样 ， 内 核 不 会 维护 信号 量 集 的 引用 计数 ， 说 
删 就 删 ， 而 且 是 立即 删除 信号 量 集 。 所 有 阻塞 在 semop 函 数 上 的 进程 将 被 唤醒 ， 返 回 错误 并 置 errno 为 





ERMUD 。 


删除 信号 量 的 示例 代码 如 下 : 





int semaphore _dqestroy (int semid) 


union semun ignored argumentysemct1l (semid, 0, IPC RMID,ignored argument) ; 


} 





2.IPC_ STAT 








用 于 获取 信号 量 集 的 信息 ， 并 存放 在 union semun 中 buf 指 向 的 结构 体 。 








每 个 信号 量 集 都 有 一 个 与 之 关联 的 semid_ds 结 构 体 (该 结构 体 无 须 自 己 定义 ) ， 它 至 少 包含 以 下 成 


I 





struct ipc perm sem perm; 
time t sem otime; 
time t sem ctime; 
unsigned long sem nsems; 





HH 
YL 
“0 


可 以 使 用 如 下 的 简单 代码 来 获取 上 述 信息 《省略 错误 处 到 








struct semid ds ds ; 
union semun arg; /大 须 确保 


Semun 联 合体 已 经 定义 


A 

arg.buf = &ds ; 

semctl1 (semid,0,IPC STAT,arg); 
printf(” 


last op time is %s\n” 


ctime(&(ds.sem otime))); 





3.IPC_SET 





union semun arg 的 成 员 变 量 buf， 可 用 来 设置 sem permuid、sem perm.gid 和 sem perm.mode。 


4.GETVAL 


返回 集合 中 第 semnum 个 信号 量 的 值 ， 无 需 第 四 个 参数 ， 示 例 代码 如 下 : 





int semaphore getval (int semid,int index) 


union semun ignored argument; 
return semctl (semid, index, GETVAL, ignored argument); 








5.SETVAL 


将 信号 量 集中 的 第 semnum 个 信号 的 值 设置 为 arg.val， 示 例 代 码 如 下 : 





int semaphore setvall(int semid, int index, int value) 


union semun arg; 
arg.val = value;return semctl (semid, index, SETVAL,arg); 








6.GETALL 


将 信号 量 集中 所 有 信和 号 的 值 存 放 在 第 四 个 参数 arg 的 成 员 变量 array 中 。 确 保有 足够 的 空间 可 以 存放 


array 数 组 。 这 个 操作 将 忽略 第 二 个 参数 semnum。 


7.SETALL 





用 第 四 个 参数 arg 的 成 员 变 量 array 数 组 中 的 值 初 始 化 信号 量 集中 的 所 有 信号 量 。 一 般 来 说 这 个 操作 
用 于 信号 量 的 初始 化 ， 正 常 使 用 期 间 很 少 会 调用 SETALL。 














需要 注意 的 是 如 果 调 用 了 SETVAL 或 SETALL， 使 用 信和 号 量 的 所 有 进程 的 semadj 都 会 被 清 零 。 


8.GETPID 














返回 上 一 个 对 第 semnum 个 信号 量 执行 semop 的 进程 的 进程 ID， 如 果 不 存 在 ， 则 返回 0。 


9.GETNCNT 





返回 等 待 第 semnum 个 信号 量 值 增 大 的 进程 的 个 数 。 





10.GETZCNT 





返回 等 待 第 semnum 个 信号 量 值 变 成 0 的 进程 的 个 数 。 


10.4 System V 共 享 内 存 


10.4.1 共享 内 存 概述 





享 内 存 是 所 有 了 PC 手段 中 最 快 的 一 种 。 它 之 所 以 快 是 因为 共享 内 存 一 旦 映射 到 进程 的 地 址 空间 ， 
进程 之 间 数 据 的 传递 就 不 须要 涉及 内 核 了 。 











回顾 一 下 前 面 已 经 讨论 过 的 管道 、FIFO 和 消息 队列 ， 任 意 两 个 进程 之 间 想 要 交换 信息 ， 都 必须 通 
过 内 核 ， 内 核 在 其 中 发 挥 了 中 转 站 的 作用 : 














:发 送信 息 的 一 方 ， 通 过 系统 调用 〈write 或 msgsnd) 将 信息 从 用 户 层 找 贝 到 内 核 层 ， 由 内 核 暂 存 这 
部 分 信息 。 








:提取 信息 的 一 方 ， 通 过 系统 调用 (read 或 msgrev) 将 信息 从 内 核 层 提取 到 应 用 层 。 
上 述 情景 如 图 10-9 所 示 。 


write/msgsnd read/msgrev 用 户 层 


内 核 层 


IPC (管道 、FIFO 或 消息 队列 ) 








图 10-9 ”管道 、FIFO 和 消息 队列 应 用 层 与 内 核 的 交互 





图 10-10 ”共享 内 存 的 思想 


一 个 通信 周期 内 ， 上 述 过 程 至 少 牵 扯 到 两 次 内 存 拷贝 《从 用 户 拷贝 到 内 核 空 间 和 从 内 核 空 间 拷贝 
到 用 户 空间 ) 和 两 次 系统 调用 ， 这 其 中 的 开销 不 容 小 靓 。 用 户 层 的 体验 固然 不 佳 ， 内 核 层 想必 也 是 不 
堪 其 扰 ， 双 方 的 内 心 都 是 骨 演 的 。 


于 是 ， 不 堪 其 扰 的 内 核 提 出 了 一 个 新 的 思路 : 共享 内 存 ， 这 种 思路 可 以 通俗 地 概括 为 内 核 拱 
进程 唱戏 。 简 单 地 说 ， 内 核 负 责 构建 出 一 片 内 存 区 域 ， 两 个 或 多 个 进程 可 以 将 这 块 内 存 区 域 映 射 到 自 
己 的 虚拟 地 址 空间 ， 从 此 之 后 内 核 不 再 参与 双方 通信 。 正 所 谓 : 














事 了 拂 衣 去 ， 深 藏 吴 与 名 。 


一 一 李白 《侠客 行 》 


进程 之 间 使 用 共享 内 存 通信 的 方式 如 图 10-10 所 示 。 

















OQ, 建立 共享 内 存 之 后 ， 内 核 完 全 不 参与 进程 间 的 通信 ， 这 种 说 法 严格 来 讲 并 不 是 正确 
的 。 因 为 当 进程 使 用 共享 内 存 时 ， 可 能 会 发 生 缺 页 ， 引 发 缺 页 中 断 ， 这 种 情况 下 ， 内 核 还 是 会 参与 进 
来 的 。 

















进程 从 此 就 像 操 作 普 通 进程 的 地 址 空间 一 样 操作 这 块 共享 内 存 ， 一 个 进程 可 以 将 信息 写 入 这 片 内 
存 区 域 ， 而 另 一 个 进程 也 可 以 看 到 共享 内 存 里 面 的 信息 ， 从 而 达到 通信 的 目的 。 








允许 多 个 进程 同时 操作 共享 内 存 ， 就 不 得 不 防范 竞争 条 件 的 出 现 ， 比 如 有 两 个 进程 同时 执行 更 新 
操作 ， 或 者 一 个 进程 在 执行 读 取 操作 时 ， 男 外 一 个 进程 正在 执行 更 新 操作 。 因 此 ， 共 享 内 存 这 种 进程 
间 通 信 的 手段 通常 不 会 单独 出 现 ， 总 是 和 信和 号 量 、 文 件 锁 等 同步 的 手段 配合 使 用 。 

















10.4.2 ”创建 或 打开 共享 内 存 


shmeget 函 数 负 责 创 建 或 打开 共享 内 存 段 ， 其 接口 定义 如 下 : 





#include <sys/ipc.h> 
#include <sys/shm.h> 
int shmget (key t key, size t size, int shmflg); 





其 中 第 二 个 参数 size 必 须 是 正 整数 ， 表 示 要 创建 的 共享 内 存 的 大 小 。 内 核 以 页 面 大 小 的 整数 倍 来 分 
配 共享 内 存 ， 因 此 ， 实 际 size 会 被 向 上 取 整 为 页 面 大 小 的 整数 倍 。 








第 三 个 参数 支持 PC_CREAT 和 IPC_EXCL 标 志 位 。 如 果 没 有 设置 PC_CREAT 标 志 位 ， 那 么 第 二 个 
参数 Size 对 共享 内 存 段 并 无 实际 意义 ， 但 是 必须 小 于 或 等 于 共享 内 存 的 大 小 ， 否 则 会 有 EINVAL 错 误 。 











和 消息 队列 及 信号 量 一 样 ， 对 于 创建 共享 内 存 ， 系 统 也 存在 一 些 限制 。 








:SHMMNI: 系统 所 能 够 创建 的 共享 内 存 的 最 大 个 数 。 


'SHMMIN: 一 个 共享 内 存 段 的 最 小 字 节 数 。 





:SHMMAX: 一 个 共享 内 存 段 的 最 大 字 节 数 。 
:SHMALL: 系统 中 共享 内 存 的 分 页 总 数 。 


:SHMSEG: 一 个 进程 允许 attach 的 共享 内 存 段 的 最 大 个 数 。 





系统 允许 创建 的 共享 内 存 的 最 大 个 数 SHMMMNI 的 硬 上 限 为 PCMNI (32768) ， 软 上 限 记 录 在 proc 文 
件 系统 的 如 下 位 置 。 





cat /proc/sys/kernel1/shmmni 
4096 





单个 共享 内 存 段 的 最 小 字 节 数 SHMMIN 是 1， 内 核 并 没有 提供 控制 选项 来 修改 这 个 值 。 实 际 上 共 亭 
内 存 会 同上 取 整 到 页 面 大 小 ， 即 共享 内 存 占用 的 内 存 总 是 页 面 大 小 的 整数 倍 ， 因 此 ， 实 际 的 限制 为 


4096 字 节 。 


单个 共享 内 存 段 的 最 大 字 节 数 为 SHMMAX。 这 个 值 默 认 是 32MB， 可 以 从 procfs 中 读 出 该 限制 。 但 
是 内 核 并 没有 设置 硬 上 限 。 





cat /proc/sys/Kkernel/shmmax 
33554432 


很 明显 ，32MB 对 某 些 大 型 的 应 用 来 说 是 不 够 用 的 。 最 里 


型 的 就 是 PostgreSQL 数 据 库 。PostgreSQL 
数据 库 会 征用 大 量 的 共享 内 存 作 为 其 内 部 使 用 的 shared_buffer。 因 此 须要 修改 该 参数 ， 方 法 为 修 
改 /etc/sysctl.conf， 新 增 如 下 内 容 ， 并 执行 sysctl-p 来 重新 加 载 。 























kernel.shmmax = 2147483648 


SHMAIL 是 一 个 系统 级 别 的 限 


关 ， 单 位 是 页 面 。 内 核 也 没有 提供 硬 上 限 ， 一 般 默 认 值 为 
2097152，2MB 个 页 面 即 2MBx4096 二 8GB。 该 限制 记录 在 procfs 的 如 下 位 置 。 








cat /proc/sys/Kernel/shmall 
2097152 














SHMSEG 是 一 个 进程 级 别 的 限制 ， 限 制 一 个 进程 最 多 可 以 attach 多 少 个 共享 内 存 段 。 内 核 事 实 上 并 
没有 特别 的 限制 ， 因 此 该 限制 实际 上 和 SHMMNI 的 值 一 样 。 











10.4.3 ”使 用 共享 内 存 




















shmget 函 数 ， 不 过 是 在 茫茫 内 存 中 创建 了 或 找到 了 一 块 共享 内 存 区 域 ， 但 是 这 块 内 存 和 进程 尚 没有 任何 关系 。 要 
想 使 用 该 共享 内 存 ， 必 须 先 把 共享 内 存 引入 进程 的 地 址 空间 ， 这 就 是 attach 操 作 。 









































attach 操 作 的 接口 定义 如 下 : 


#include <sys/types.h> 
#include <sys/shm.h> 
void *shmat (int shmid, const void *shmaddr, int shmflg); 




















其 中 ， 第 二 个 参数 是 用 来 指定 将 共享 内 存放 到 虚拟 地 址 空间 的 什么 位 置 的 。 大 部 分 的 普通 青年 都 会 将 第 二 个 参数 
设置 为 NULL， 表 示 用 户 并 不 在 意 ， 一 切 交 由 内 核 做 主 。 





























AI 


当 shmaddr 的 地 址 不 是 NULL 的 时 候 ， 表 示 进 程 希望 将 共享 内 存 attach 到 该 地 址 。 但 是 该 地 址 必须 是 系统 分 页 的 整数 












































倍 ， 和 否则 会 返回 EINVAL 错 误 。 内 核 提 供 了 一 个 shmflg 为 SHM RND， 表 示 该 地 址 不 是 系统 分 页 的 整数 倍 也 没关系 ， 系 
统 会 在 用 户 给 出 的 地 址 附近 ， 就 近 找 一 个 系统 分 页 整数 倍 的 地 址 。 
































如 果 指 定 的 shmaddr 落 在 已 经 在 用 的 地 址 范围 内 ， 就 会 导致 EINVAL 错 误 。 但 是 Linux 提 供 了 一 个 非 标准 的 扩展 
SHM_REMAP。 这 个 标志 位 表示 替换 位 于 shmaddr 处 且 长 度 为 共享 内 存 段 的 长 度 的 任何 内 存 映 射 。 很 明显 ， 设 置 了 
SHM_REMAP 标 志 位 ，shmaddr 参 数 就 不 能 再 为 NULLT 。 























如 果 进 程 仅仅 是 读 取 共享 内 存 段 的 内 容 ， 并 不 修改 ， 则 可 以 指定 SHM_RDONLY 标 志 位 。 











shmat 如 果 调 用 成 功 ， 则 返回 进程 虚拟 地 址 空间 内 的 一 个 地 址 。 如 果 失 败 ， 就 会 返回 (void*) -1， 并 且 设 置 


errnoOo 



























































如 何 通过 shmat 返 回 的 地 址 来 使 用 共享 内 存 ? 答案 是 像 使 用 malloc 分 配 的 空间 一 样 使 用 共享 内 存 。 我 们 都 使 用 过 
malloc， 调 用 malloc 时 ， 会 指定 分 配 空间 的 大 小 ，malloc 成 功 后 ， 可 以 正常 地 使 用 返回 的 地 址 (只 要 不 超过 分 配 的 空 
间 ) 。shmat 也 是 一 样 ， 程 序 员 可 以 自如 地 使 用 shmat 返 回 的 地 址 。 






























































使 用 共享 内 存 和 使 用 malloc 分 配 的 空间 还 是 有 区 别 的 。 共 享 内 存 段 用 于 多 个 进程 间 的 通信 ， 因 此 ， 写 入 共享 内 存 
的 内 容 要 事先 约定 好 ， 读 取 进 程 才 可 以 正常 地 解析 写 入 进程 写 入 的 内 容 。malloc 分 配 的 内 存 区 域 完 全 归 调 用 进程 所 


9， 其 他 进程 不 可 见 ， 但 共享 内 存 则 不 然 ， 其 他 进程 也 可 能 会 同时 操作 该 共享 内 存 ， 因 此 使 用 者 要 有 进程 间 同 步 的 觉 


悟 。 

































































































































































下 面 给 出 一 个 将 共享 内 存 attach 到 进程 地 址 空间 的 例子 : 





#include <stdio.h> 
#include <stdlib.h> 
#include <sys/types.h> 
#include <sys/shm.h> 
#include <errno.h> 
#include <string.h> 
#define MYKEY 0x3333 
int main() 
{ 
int shmid; 
void *ptr = NUL 
shmid = shmget ey 4096, IPC CREAT | IPC EXCL |0640); 
if(shmid == -1 ) 


if(errno != EEXIST) 
{ 


fprintf (stderr,"shmget returned %d (%d: %s)\n", 
shmid, errno,strerror (errno)) 
return 1; 
} 
全 上 上 二 全 
{ 
shmid = shmget (MYKEY, 4096,0); 
if(shmid == -1) 
{ 


’ 


fprintf (stderr,"shmget returned %d (%d: %s)\n", 
shmid, errno, strerror(errno)); 
return 2; 
} 
} 
} 
fprintf (stdout,"shmid = %d\n",shmid); 
ptr = shmat (shmid, NULL, SHM RND); 
if(ptr == (void*)-1) 
{ 
fprintf (stderr,"shmat return NULL, errno (%d: %s)\n", 
errno, strerror (errno)); 
return 2; 
} 
fprintf (stdout,"shmat returned %p\n", ptr); 
sleep (1000); 
shmdt (ptr) ; 
return 0; 





当 执 行 上 述 程序 时 ， 可 以 看 到 如 下 输出 : 











./shm 
shmid = 131075 
shmat returned 0x7f555qc5c000 





可 以 看 到 返回 的 标识 符 儿 为 131075， 该 共享 内 存 attach 到 进程 的 地 址 空间 后 ， 在 进程 内 的 地 址 为 0x7f555dc5c000。 








通过 查看 进程 的 地 址 空间 ， 也 可 以 看 出 共享 内 存 所 在 的 位 置 ， 代 码 如 下 : 

















cat /Proc/9058/maps. 


7f34c6de8000-7f34c6de9000 rw-s 00000000 00:04 131075 
/SYSV00003333 (deleted).. 





上 述 输出 中 ， 字 上段 的 含义 如 图 10-11 所 示 。 





在 进程 地 址 空间 的 位 置 标识 符 ID 键 值 





7f34c6de8000_7f34c6de9000 |rw-s| 00000000 | 00:04 | 131075 /SYSV00003333 
(deleted) 


10-11 /proc/PID/maps 中 的 共享 内 存 段 


共享 内 存 和 System V 消 息 队 列 及 System V 信 号 量 有 不 同 之 处 ， 共 享 内 存 维护 了 attach 该 共享 内 存 的 进程 的 个 数 ， 见 
下 面 输出 的 nattach 列 : 





ipcs -m 
be Shared Memory Segments --------— 
key shmid owner perms bytes nattch status 


0x07021999 196608 root 644 L712 2 





就 删 的 准则 ， 














E 猜 出 共享 内 存 的 删除 和 消息 队列 及 信和 号 量 的 删除 是 不 同 的 。 它 并 不 遵循 说 册 
内 存 的 进程 个 数 。 如 果 尚 有 进程 在 使 用 该 共享 内 存 ， 就 不 会 真正 地 删除 ， 而 是 让 内 核 负 责 标 























存在 引用 计数 ， 就 不 难 
删除 时 会 判断 attach 该 共享 


记 一 下 就 返回 了 。 




















了 ， 应 该 及 时 地 将 共享 内 存 























外 认 不 再 使 月 
































正 是 因为 attach 操 作 会 影响 删除 的 行为 ， 因 此 ， 使 用 共享 内 存 的 进程 如 果 古 
分 离 ， 使 其 离开 进程 的 地 址 空间 ， 这 就 是 分 离 操 作 。 分 离 会 使 共享 内 存 的 引用 计数 减 1。 
通过 fork 函 数 创建 的 子 进程 ， 会 继承 父 进程 attiach 的 共享 内 存 。 因 此 在 fork 之 前 创建 共享 内 存 ， 后 面 父子 进程 就 可 






















































































以 使 用 这 块 共享 内 存 进行 通信 了 。 





分 离 操 作 的 接口 定义 如 下 : 





#include <sys/types.h> 
#include <sys/shm.h> 
int shmdt (const void *shmaddr); 





shmdt 函 数 仅 仅 是 使 进程 和 共享 内 存 脱离 关 系 ， 并 未 删除 共享 内 存 。shmdt 函 数 的 作用 是 将 共享 内 存 
的 引用 计数 减 1。 如 前 所 述 ， 只 有 共享 内 存 的 引用 计数 为 0 时 ， 调 用 shmct 函 数 的 PC_RMID 命 令 才 会 真 
正 地 删除 共享 内 存 。 





进程 执行 exec 之 后 ， 所 有 attach 的 共享 内 存 都 会 被 分 离 。 当 进程 终止 之 后 ， 共 享 内 存 也 会 自动 被 分 





10.4.5 ”控制 共享 内 存 








shmctl 函 数 用 来 控制 共享 内 存 ， 函 数 接口 定义 如 下 : 





#include <sys/ipc.h> 
#include <sys/shm.h> 
int shmctl(int shmid, int cmd, struct shmid ds *buf); 





当 cmd 为 IPC_STAT 和 IPC_SET 时 ， 需 要 用 到 第 三 个 参数 。 其 中 shmid_ds 结 构 体 的 定义 如 下 : 





struct shmid ds { 
struct ipc perm shm perm; 





SiZe 和 shm segsz; 
time t shm atime; 
time t shm dtime; 
time t shm ctime; 
pid 七 shm cpig; 
pid 七 shm lpig; 
shmatt 七 shm nattch; 
}; 
1.IPC_STAT 











用 于 获取 shmid 对 应 的 共享 内 存 的 信息 。 所 谓 信息 ， 就 是 上 面 结构 体 的 内 容 。 





shm perm 中 的 mode 字 段 有 两 个 比较 特殊 的 标志 位 ， 即 SHM_DEST 和 SHM_LOCKED。 





删除 共享 内 存 时 ， 可 能 由 于 attach 它 的 进程 个 数 不 为 0， 因 此 只 能 打上 一 个 标记 ， 表 示 标 记 删 除 ， 待 
到 所 有 attach 该 共享 内 存 的 进程 都 执行 过 分 离 〈detach) 操作 ， 共 享 内 存 的 引用 计数 变 成 0 之后， 才 执 行 
真正 的 删除 操作 。 所 谓 的 标记 指 的 就 是 SHM_DEST 标 志 位 。 


对 于 已 经 标记 删除 的 共享 内 存 ， 可 以 通过 ipcs-m 命 令 的 status 栏 来 查看 ， 其 dest 含 义 是 已 经 标记 删除 
的 意思 。 





shmid owner perms bytes nattch status 
a 32768 root 666 4096 由 dest 





可 以 通过 shmctl 的 SHM_LOCK 操 作 将 一 个 共享 内 存 段 锁 入 内 存 ， 这 样 它 就 不 会 被 置换 出 去 。 这 样 做 
的 好 处 是 访问 共享 内 存 的 时 候 ， 不 会 产生 缺 页 中 断 (page fault) 。 





通过 ipcs-m 的 输出 可 以 查看 共享 内 存 是 否 被 锁 入 内 存 ， 注 意 下 面 状 态 中 的 locked 字 段 ， 该 字段 表明 
对 应 的 共享 内 存 已 被 锁 入 内 存 。 








ipcs -m 
二 二 Shared Memory Segments ------——-— 

shmid owner perms bytes nattch status 
oe 32768 manu 640 4096 由 locked 





除 此 以 外 ， 其 他 字段 就 顾名思义 了 。 


.shm_segsz: 共享 内 存 的 字 节 数 。 





shm atime: 创建 共享 内 存 时 设置 成 0， 当 进程 通过 shmat 函 数 attach 共 享 内存 时 ， 将 时 间 更 新 为 当前 
时 间 。 





“shm _dtime: 创建 共享 内 存 时 设置 成 0， 当 进程 调用 shmdt 分 离 共 享 内 存 时 ， 将 时 间 更 新 成 当前 时 





:shm ctime: 当 创建 共享 内 存 时 ， 设 置 该 值 为 当前 时 间 ;， 当 调 用 IPC_SET 操 作 时 ， 更 新 该 值 为 当前 
时 间 。 








“shm _nattch: attach 该 共享 内 存 到 其 地 址 空间 的 进程 的 个 数 。 





2.IPC SET 
IPC_SET 也 只 能 修改 shm_perm 中 的 uid、gid 及 mode。 
3.IPC RMID 


可 以 通过 如 下 方式 删除 共享 内 存 段 ， 








ret = shmctl (shmid, IPC RMID, (struct shmid ds *) NULL); 











如 果 共 享 内 存 的 引用 计数 shm_nattch 等 于 0， 则 可 以 立即 删除 共享 内 存 。 但 是 如 果 仍 然 存在 进程 
attach 该 共享 内 存 ， 则 并 不 执行 真正 的 删除 操作 ， 而 仅仅 是 设置 SHM_DEST 标 记 。 待 所 有 进程 都 执行 过 
分 离 操作 之 后 ， 再 执行 真正 的 删除 操作 。 











值得 一 提 的 是 ， 共 享 内 存 处 于 SHM_DEST 状 态 的 情况 下 ， 依 然 允许 新 的 进程 调用 shmat 函 数 来 attach 
该 共享 内 存 。 


4.SHM LOCK 





可 以 通过 如 下 方式 将 共享 内 存 锁定 在 内 存 之 中 : 








ret = shmctl(shmid, SHM LOCK, (struct shmid ds *) NULL); 





上 面 的 代码 会 将 共享 内 存 锁定 在 RAM 中 ， 而 不 被 置换 出 去 。 这 种 做 法 可 以 提升 共享 内 存 的 访问 性 
。 因 为 进程 在 访问 共享 内 存 所 在 的 分 页 时 ， 不 会 因 缺 页 中 断 而 导致 性 能 下 降 。 














注意 调用 SHM _ LOCK 并 不 能 保证 在 shmct 函 数 结束 时 ， 所 有 的 共享 内 存 页 已 经 位 于 RAM 中 了 ， 当 
没有 驻 留 在 RAM 中 的 页 面 因 为 访问 需要 ， 由 缺 页 中 断 而 被 引入 RAM 后 ， 该 页 面 就 会 被 锁定 ， 而 不 会 被 
交换 出 去 。 除 非 调用 了 下 面 提 到 的 SHM_UNLOCK， 否 则 页 面 会 一 直 驻 留 在 内 存 中 。 


























SHM LOCK 设 置 的 是 共享 内 存 的 属性 ， 而 不 是 进程 的 属性 ， 所 以 哪怕 所 有 attach 共 享 内 存 的 进程 都 
己 终 止 ， 共 享 内 存 的 页 面 仍 被 锁定 在 RAM 中 。 故 而 为 了 防止 发 生 资 源 汇 漏 ， 要 及 时 解锁 已 锁定 的 共享 
内 存 。 解 锁 操 作 可 通过 shmctl 函 数 的 SHM_UNLOCK 来 完成 。 














5.SHM UNLOCK 


SHM_UNLOCK 操 作 和 SHM_LOCK 操 作 相 反 ， 是 解锁 操作 ， 即 允许 共享 内 存 的 页 面 被 交换 出 去 。 可 
以 通过 如 下 方式 解锁 共享 内 存 : 


ret = shmctl(shmid, SHM UNLOCK, (struct shmid ds *) NULL); 


第 11 章 ”进程 间 通 信 : POSIX IPC 


与 System VIPC 一 样 ，POSIX IPC 也 包含 三 种 类 型 : 





:POSIX 消 息 队 列 











`POSIX 信 号 量 〈 又 分 为 命名 信号 量 和 无 名 信号 量 ) 





:POSIX 共 享 内 存 











POSIX IPC 的 出 现 要 比 System VIPC 晚 ， 因 此 POSIX PC 的 设计 者 可 以 从 容 地 参照 System VIPC， 吸 收 其 设计 上 的 长 处 ， 规 避 其 设计 上 的 缺 
点 。 正 是 由 于 POSIX IPC 拥 有 后 发 优势 ， 所 以 总 体 来 讲 ，POSIX PC 要 优 于 System V IPC。 


| 

















表 11-1 汇 总 了 POSIX IPC 的 所 有 函数 。 





表 11-1 POSIX IPC 函 数列 表 


t 
os mq_send A pe i 
执行 IPC rp sem wait 在 共享 内 存 区 域内 操作 数据 
二 sem getvalue 


mq getattr 


i sem init (初始 化 未 命名 信号 量 
其 他 果 作 mq_setattr 加 一 名 信 ” i 无 


mq_notify 





11.1 POSIX PC 概述 


在 POSIX IPC 的 模型 中 ， 对 open、close 和 unlink 等 类 似 函 数 《〈 见 表 11-1 创 建 或 打开 、 关 闭 和 删除 三 
行 ) 的 使 用 与 传统 的 Unix 文 件 模型 一 致 ， 相 信 理 解 和 操作 起 来 应 该 很 容易 。 


与 打开 文件 一 样 ，POSIX IPC 对 象 也 有 引用 计数 ， 内 核 会 负责 维护 PC 对 象 上 的 打开 引用 计数 。 它 
所 带 来 的 影响 是 删除 POSIX IPC 对 象 的 操作 比较 简单 。 删 除 操作 仅仅 是 删除 PC 对 象 的 名 字 ， 等 所 有 的 
进程 都 使 用 完毕 ，IPC 对 象 的 引用 计数 变 成 0 之 后 才 真 正 销毁 IPC 对 象 。 








11.1.1 IPC 对象 的 名 字 


多 个 进程 之 间 操 作 同 一 个 PC 对 象 ， 总 要 有 个 入 口 点 或 线索 ， 以 便 根据 线索 找到 共同 的 人 PC 对 象 。 





对 于 System V IPC 而 言 ， 键 值 就 是 其 线索 ， 只 要 拿 着 相同 的 键 值 就 能 找到 同一 个 System VIPC 对 象 
(如 图 11-1 所 示 ) 。 


System V IPC 
filename ftok ke We 
” 
key System V IPC 
( magic number ) 标识 符 


11-1 SystemVIPC 顺 藤 摸 瓜 之 项 





对 于 POSIX IPC 来 说 ， 可 以 像 操 作文 件 一 样 操 作 IPC 对 象 。 文 件 有 路 径 名 ， 同 样 ，IPC 对 象 也 有 IPC 
对 象 的 名 字 。SUSv3 标 准 规定 ， 唯 一 一 种 用 来 标识 POSIX IPC 对 象 的 可 移植 方法 是 使 用 以 斜 线 打头 后 面 
跟着 一 个 或 多 个 非 斜 线 字 符 的 名 字 ， 如 /myobject。 








下 面 三 段 代码 分 别 负责 创建 POSIX 消 息 队 列 、 信 号 量 和 共享 内 存 。 








/* 创 建 


POSIX 消 息 队 列 


*/ 

mqd t mqd = mq openl(argv[1],O RDWR|O CREAT|O EXCL,S IRUSR|S IWUSR,NULL); 
if (mqd == -1) 
{ 





/*error handle*/ 


/* 创 建 


POSIX 信 号 量 


</ 
Sem tx sem = Sem openl(argv[1],O CREAT|O EXCL,S IRUSR|S IWUSR,1); 
if (sem == SEM FAILED) 
{ 


/*error handle*/ 











} 
/* 创 建 


POSIX 共享 内 存 


«7 
int shm fd= shm open(argv[1],O RDWR|O CREAT|O EXCL,S IRUSR|S IWUSR); 
if(shm fd == -1) 
{ 
/*error handle*/ 


} 











Linux 为 IPC 对 象 提供 了 文件 系统 的 访问 接口 ， 即 可 以 像 操 作 普 通 文 件 一 样 操作 IPC 对 象 。 





对 于 创建 出 来 的 共享 内 存 和 信号 量 ，Linux 将 这 些 对 象 放 到 了 挂 载 在 /dev/shm 目 录 处 的 tmpfs 文 件 系 
统 中 ， 代 码 如 下 所 示 : 





11 /dev/shm/ 

total 0 

drwxrwxrwt 2 root root 40 Sep 12 05:08 ./ 
drwxr-xr-x 20 root root 780 Sep 12 04:22 .. /创建 名 为 


albbc 的 


POSIX 共 享 内 存 之 后 


./shm open abc 

11 /dev/shm/ 

total 0 

drwxrwxrwt 2 root root 60 Sep 12 05:13 ./ 


drwxr-xr-x 20 root root 780 Sep 12 04:22 ../ 
a A 1 manu manu 0 Sep 12 05:13 abc 创 建 名 为 
abc 的 


./sem open abc 

11 /dev/shm/ 

total 4 

drwxrwxrwt 2 root root 80 Sep 12 05:14 ./ 
drwxr-xr-x 20 root root 780 Sep 12 04:22 ../ 
EW 1 manu manu 0 Sep 12 05:13 abc 
生计 1 manu manu 32 Sep 12 05:14 sem.abc 











可 以 看 到 ， 创 建 一 个 名 为 name 的 共享 内 存 后 ， 在 /dev/shm 目 录 下 就 会 有 一 个 名 为 name 的 文件 。 如 果 
创建 一 个 名 为 mame 的 信号 量 ， 那 么 在 /dev/shm 目 录 下 就 会 有 一 个 名 为 sem.name 的 文件 。 














消息 队列 也 可 以 展现 在 文件 系统 中 ， 不 过 要 比 共享 内 存 和 信号 量 稍微 复杂 一 些 。 需 要 首先 将 消息 
队列 挂 载 到 文件 系统 中 ， 方 法 如 下 : 








mkdir /dev/mqueue 
mount -— 





t mqueue none /dev/mqueu 


现在 可 以 创建 消息 队列 了 。 当 然 如 果 不 将 消息 队列 挂 载 到 文件 系统 中 ， 并 不 会 影响 消息 队列 的 创 
建 ， 仅 仅 是 无 法 从 文件 系统 查看 消息 队列 的 情况 而 已 。 














11 /dev/mqueue/ 

total 0 

drwxrwxrwt 2 root root 40 Sep 12 05:29 ./ 
drwxr-xr-x 17 root root 4260 Sep 12 03:57 .. /创建 一 个 名 为 


/abc 的 


POSIX 消 息 队 列 


./mq_open /abc 

11 /dev/mqueue/ 

total..0 

drwxrwxrwt 2 root root 60 Sep 12 05:41 ./ 

drwxr-xr-x 17 root root 4260 Sep 12 03:57 ../ 
研 下 人 一 二 二 一 二 一 一 1 manu manu 80 Sep 12 05:41 abc 


IPC 对 象 的 名 字 有 哪些 限制 ? 通过 测试 不 难得 出 以 下 结论 : 





:POSIX 消 息 队 列 的 名 字 必 须 以 /打头 ， 而 且 后 续 字 符 不 允许 出 现 /， 否 则 就 返回 EINVAL 错 误 。 


`POSIX 消 息 队 列 的 名 字 中 打头 的 /字符 不 计 入 长 度 。 











.POSIX 消 息 队 列 名 字 的 最 大 长 度 为 NAME MAX (255 个 字符 ) ， 若 超过 则 返回 ENAMETOOLONG 


错误 。 








`POSIX 信 号 量 和 共享 内 存 的 名 字 可 以 以 1 个 或 多 个 /打头 ， 也 可 以 不 以 /打头 。 








`POSIX 信 和 号 量 和 共享 内 存 的 名 字 中 ， 打 头 的 一 个 或 多 个 /字符 不 计 入 长 度 。 




















.POSIX 共 享 内 存 名 字 的 最 大 长 度 为 NAME MAX，POSIX 信 和 号 量 名 字 的 最 大 长 度 为 NAME MAX- 
4 因为 实现 会 在 信号 量 的 名 字 前 面 添加 sem. 这 4 个 字符 ) 。 若 超过 则 返回 ENAMETOOLONG 和 错误 。 











注意 ， 这 些 结论 是 从 glibc 相 关 函 数 (mq _open、sem open 和 shm open) 的 角度 来 分 析 的 ， 并 不 是 从 
系统 调用 的 角度 来 分 析 的 。8slibc 调 用 系统 调用 之 前 会 做 一 些 动作 ， 比 如 mq_open 函 数 调用 同名 系统 调用 
前 会 去 除 打 头 的 /等 。 





11.1.2 ”创建 或 打开 IPC 对 象 








解决 了 IPC 对 象 的 名 字 问 题 ， 接 下 来 就 是 创建 POSIX 了 PC 对 象 了 。 创 建 或 打开 ， 都 是 由 open 系 列 函数 来 完成 的 。 后 续 的 操作 要 作用 在 open 函 数 

















返回 的 句柄 上 。 





对 于 POSIX IPC 的 open 系 列 函数 而 言 ， 一 般 至 少 包 含 三 个 参数 name、oflag 和 mode( 见 表 11-2)。 

















name 前 面 已 经 说 过 ， 就 是 POSIX IPC 的 名 字 。 下 面 来 分 析 第 二 个 参数 打开 标志 位 。 

















表 11-2 POSIX IPC open 中 的 标志 位 


若 不 存在 则 创建 O_CREAT 
排他 性 创建 5 BXEL 


非 阻塞 模式 O NONBLOCK 


SEA | | 


YY 


心 











shm_open 


O_RDONLY 
O_RDWR 
O_CREAT 


O_EXCL 


O_TRUNC 


如 果 oflag 中 指定 了 O_CREAT 标 志 位 ， 则 需要 第 三 个 参数 mode 来 指定 权限 ， 这 个 权限 和 文件 的 权限 一 样 ， 不 外 乎 S_IRUSR、S_IWUSR、 
S IRGRP、S_IWGRP、S_IROTH 及 S_IWOTH 这 6 种 权限 。 并 且 和 open 函 数 一 样 ，mode 中 的 权限 会 根据 进程 的 umask 取 掩 码 。 














打开 还 是 创建 ， 取 决 于 oflag 是 否 设置 了 O_CREAT 及 O_EXCL 标 志 位 。 内 在 的 控制 逻辑 和 System V 了 了 C 一 致 ， 如 表 11-3 所 示 。 
































表 11-3 POSIX IPCO_CREATE 和 O_EXCL 标 志 位 的 影响 


oflag 标志 位 对 象 不 存在 
无 特殊 标志 出 错 ，errno 为 ENOENT 
O_CREAT 成 功 ， 创 建新 对 象 





O_CREAT |O EXCL 成 功 ， 创 建新 对 象 


对 象 存在 
成 功 ， 引 用 已 存在 对 象 
成 功 ， 引 用 已 存在 对 象 
失败 ，errno 为 EEXIST 


11.1.3 ”关闭 和 删除 了 PC 对 象 


POSIX IPC 对 象 维护 有 引用 计数 ， 在 用 完 PC 对 象 后 ， 可 以 调用 相关 的 close 函 数 来 释放 与 该 对 象 关 
联 的 资源 并 使 引用 计数 减 1。 对 于 消息 队列 ， 该 函数 是 mq_close; 对 于 信和 号 量 该 函数 是 sem_close。 共 享 
内 存 和 前 两 者 略 有 不 同 ， 它 通过 munmap 解 除 映 射 来 解除 和 共享 内 存 的 关系 。 








当 进程 退出 或 执行 exec 系 列 函 数 时 ，IPC 对 象 会 自动 关闭 。 


正 是 因为 POSIX IPC 对 象 有 引用 计数 ， 所 以 删除 的 时 候 比较 方便 。 对 应 的 unlink 操 作 会 删除 对 象 的 
名 字 ， 直 到 所 有 进程 使 用 完毕 ， 关 闭 了 对 象 或 解除 了 映射 关系 之 后 ， 才 会 真正 销毁 。 








因为 Linux 提 供 了 文件 系统 访问 方式 ， 因 此 完全 可 以 在 文件 系统 中 执行 ls 或 rm 操作 来 查看 或 删除 了 PC 
对 象 。 细 心 的 读者 可 以 看 出 存放 IPC 对 象 的 目录 都 设置 了 粘 滞 位 ， 这 是 用 来 保护 目录 下 的 文件 的 ， 即 对 
于 非特 权 进 程 只 能 删除 它 自 己 拥有 的 POSIX IPC 对 象 。 





11 /dev/shm/ 

total 0 

drwxrwxrwt 2 root root 40 Sep 12 07:08 ./ 
11 /dev/mqueue/ 

total 0 

drwxrwxrwt 2 root root 40 Sep 12 07:08 ./ 


11.1.4 其 他 











与 System V IPC 相 比 ，POSIX 有 很 多 优势 。 后 面 介绍 POSIX PC 的 每 一 种 通信 手段 的 时 候 ， 都 会 与 
System V IPC 对 应 的 手段 进行 比较 。 但 POSIX IPC 也 有 明显 的 劣势 一 可 移植 性 。 因 为 System V 出 现 得 
早 ， 几 乎 所 有 的 Unix 平 台 都 支持 System V IPC。 但 是 如 果 专 注 于 Linux 平 台 的 话 ， 这 个 问题 就 不 存在 了 。 
2.6.6 之 后 的 内 核 版 本 ， 三 种 POSIX IPC 手 段 就 己 经 齐备 。 而 主流 在 用 的 Linux 版 本 很 少 有 低 于 2.6.6 的 。 
































编译 使 用 POSIX IPC 的 程序 时 需要 注意 以 下 两 点 。 








: 当 使 用 消息 队列 和 共享 内 存 的 时 候 ， 需 要 和 实时 库 librt 链 接 起 来 。cc 命 令 中 需 指 定 -lrt。 





当 使 用 信和 号 量 的 时 候 ， 需 要 和 线程 库 libpthread 链 接 起 来 。cc 命 令 中 需 指定 -Ipthread。 
示例 代码 如 下 所 示 : 


gcc -o mq open mq open.c - 


二 到 起 
gcc -oO shm open shm open.c -1rt 
gcc -0o sem open sem open.c - 


lpthread 


11.2 POSIX 消 息 队 列 














POSIX 消 息 队 列 与 System V 消 息 队 列 有 一 定 的 相似 之 处 ， 信 息 交 换 的 基本 单位 是 消息 ， 但 也 有 显著 





最 大 的 区 别 当 属 在 Linux 实 现 里 POSIX 消 息 队 列 的 句柄 本 质 是 文件 描述 符 。 这 个 性 质 给 POSIX 消 息 队 
列 带 来 了 巨大 的 优势 。 因 为 是 文件 描述 符 ， 所 以 可 以 使 用 VO 多 路 复 用 系统 调用 (select、poll 或 epoll 
等 ) 来 监控 这 个 文件 描述 符 。 
































其 次 ，POSIX 消 息 队 列 提供 了 通知 功能 ， 当 消息 队列 中 有 消息 可 用 时 ， 就 会 通知 到 进程 。 而 System 
V 消 息 队 列 没有 通知 功能 ， 所 以 消息 队列 上 何 时 有 消息 进程 无 从 得 知 ， 只 能 阻塞 (msgrev) 或 轮 询 ( 带 





IPC NOWAIT 标 志 位 的 msgrcv) 。 








最 后 ，System V 消 息 队 列 的 消息 提取 要 比 POSIX 消 息 队 列 灵活 。POSIX 消 息 队 列 本 质 是 个 优先 级 队 
列 。 而 System V 消 息 中 存在 类 型 字段 ， 可 以 提取 类 型 等 于 某 值 的 消息 ， 这 点 POSIX 消 息 队 列 是 做 不 到 
的 。 这 个 优势 让 System V 消 息 队 列 在 与 POSIX 消 息 队 列 的 对 决 中 ， 稍 稍 挽回 一 点 颜面 。 
































11.2.1 消 妃 队列 的 创建 、 打 开 、 关 闭 及 删除 


之 所 以 在 本 节 介 绍 三 个 接口 ， 是 因为 POSIX 消 息 队列 的 接口 和 操作 文件 的 接口 非常 类 似 。 


消息 队列 的 mq_open 函 数 如 同 操作 文件 的 open 函 数 ， 用 于 创建 或 打开 一 个 消息 队列 ， 其 接口 定义 如 


下 : 


#include <fcntl.h> 

#include <sys/stat.h> 

#include <mqueue.h> 

mad 七 mq openl(const char *name, int oflag); 

mqd 七 mq openl(const char *name, int oflag, mode t mode, 
struct mq attr *attr); 


oflag 允 许 的 标志 位 包括 O_ RDONLY、O_WRONLY、O RDWR、O_CREAT、O_EXCL 及 


O NONBLOCK. 


除了 O_NONBLOCK 标 志 位 ， 其 他 都 是 老 朋 友 了 ， 不 必 凌 述 ， 这 里 单 提 一 下 O_NONBLOCK。 如 果 打 
开 消 息 队 列 时 ， 没 有 设置 ONONBLOCK 标 志 位 ， 那 么 后 续 的 mq_send 调 用 和 mq_receive 调 用 就 可 能 会 陷入 


























阻塞 。 反 之 ， 如 果 打 开 消 息 队 列 时 设置 了 该 标志 位 ， 发 送 消 妃 或 接受 消息 若 不 能 立刻 返回 





， 则 立刻 返回 








失败 ， 并 置 errno 为 EAGAIN， 而 不 会 陷入 阻塞 。 





第 三 个 参数 mode 和 第 四 个 参数 attr 只 有 在 创建 消息 队列 的 时 候 才 有 意义 。 如 果 仅 仅 是 打开 消息 队列 ， 
则 无 需 这 两 个 参数 。mode 设 置 的 是 访问 权限 ，attr 设 置 的 是 消息 队列 的 属性 。 在 介绍 mq_getatttr 函 数 和 
mq_setattt 辫 数 时 会 展开 说 明 。 上 默认 情况 下 ， 第 四 个 参数 可 以 传递 NULL， 表 示 创 建 默 认 属 性 的 消息 队列 。 














当 mq_open 调 用 成 功 时 则 返回 一 个 mqd t 类 型 的 消息 队列 描述 符 。 对 于 Linux 平 台 而 言 ， 














这 就 是 一 个 int 


型 数字 ， 其 实 这 个 数字 和 open 函 数 返回 的 文件 描述 符 本 质 上 是 一 样 的 ， 从 内 核 的 ipc/mqueue.c 中 mq_open 


系统 调用 的 实现 就 可 以 看 出 : 


SYSCALL _ DEFINE4 (mgq open, const char user *, u name, int, oflag, mode t, mode,struct mq attr user *, u attr) 


fd = get unused fd flags(O CLOEXEC); 





return faq; 


} 


在 /proc/PID/ 包 目录 下 ， 也 可 以 看 到 消息 队列 对 应 的 文件 描述 符 ; 





./ma_open /abc 
11 /proe/2925/f£d 


lrwx—————-— 1 manu manu 64 Sep 13 09:04 3 -> /abc 








一 个 进程 允许 打开 多 少 个 消息 队列 ? 标准 并 没有 严格 限定 ， 这 点 是 由 具体 的 实现 来 决定 的 。SUSv3 














标准 要 求 这 个 限制 最 小 为 POSIX MQ_OPEN MAX (8) 。Linux 没 有 定义 这 个 限制 。 相 反 

















因为 消息 描述 





符 被 实现 成 了 文件 描述 符 ， 因 此 其 必须 遵循 文件 描述 符 的 限制 。 











进程 允许 打开 的 消息 队列 个 数 是 否 仅 仅 受 限于 进程 打开 的 最 大 文件 个 数 ? 事实 上 并 非 如 此 。 资 源 限 
制 中 有 一 项 RLIMIT MSGQUEUE， 用 于 限制 用 户 在 POSIX 消 息 队 列 中 可 以 分 配 的 最 大 字 节 数 。 在 下 一 节 
介绍 POSIX 消 息 队 列 的 属性 时 ， 会 重点 介绍 该 限制 对 允许 打开 的 消息 队列 个 数 的 影响 。 

















调用 fork 之 后 ， 子 进程 也 获得 了 消息 队列 描述 符 的 副本 ， 这 个 副本 会 引用 同样 的 打开 的 消息 队列 。 


eA 


























调用 exec 之 后 ， 由 于 内 核实 现 中 消息 队列 的 描述 符 自动 带 有 O_CLOEXEC 标 志 位 ， 所 以 其 打开 的 消息 
队列 会 被 自动 关闭 。 


























当 进 程 退 出 时 ， 所 有 打开 的 消息 队列 都 会 被 关闭 。 











mq_close 函 数 用 于 关闭 消息 队列 描述 符 ， 这 个 函数 和 关闭 文件 的 close 函 数 十 分 类 似 : 





#include <mqueue.h> 
int mq close(mqd 七 mqdes); 
























































如 果 进 程 已 经 注册 了 消息 通知 ， 那 么 消息 通知 也 会 被 删除 。 因 为 任 一 时 刻 ， 只 能 有 一 个 进程 向 特定 
消息 队列 注册 并 接收 消息 通知 ， 因 此 删除 消息 通知 后 ， 其 他 进程 就 能 注册 消息 通知 了 。 



































POSIX 消 息 队 列 也 具有 内 核 持 久 性 ， 纵 然 打 开 该 消息 队列 的 所 有 进程 都 执行 了 mq_close， 消 息 队 列 的 
引用 计数 已 变 为 0， 但 只 要 不 显 式 地 调用 mq_unlink， 该 队列 及 队列 上 的 消息 依然 存在 。 要 销毁 消息 队列 ， 
需要 调用 mq_unlink 函 数 ， 代 码 如 下 : 

















#include <mqueue.h> 
int mq unlink(const char *name); 











下 面 通过 两 个 测试 程序 来 学 习 消息 队列 的 创建 。 





第 一 个 小 程序 是 用 来 创建 消息 队列 的 ， 如 果 传 入 了 -e 选 项 ， 则 表示 创建 时 要 加 上 O_EXCIL 标 志 位 : 











#include <mqueue.h> 
#include <stdio.h> 
#include <sys/stat.h> 
#include <stdlib.h> 
#include <unistd.h> 
#include <errno.h> 
#include <string.h> 
int main(int argc,char *argv[]) 
{ 

int c,flags; 

mqd t mqad; 


flags = O_RDWR|IO_ CREAT; 
while( (c=getopt (argc,argv, "e") !=-1) 
Switch (c) 
{ 
Case 'e': 
flags |= O EXCL; 
break; 


} 


} 
if (optind!=argc-1) 
{ 


fprintf (stderr, "usage:mqcreate [-e]l <name>\n"); 
return =1; 
} 
mqd = mq open (argv[optind],flags,S IRUSR|S IWUSR,NULL); 
if mad == -1) 
{ 
fprintf (stderr, "mq open failed (%s)\n", 
strerror (errno)); 
return -2; 


} 
mq_close (mad) 
return 0; 





第 二 个 小 程序 是 用 来 删除 POSIX 消 息 队列 的 : 








#include <mqueue.h> 

#include <stdio.h> 

#include <stdlib.h> 

#include <errno.h> 

#include <string.h> 

int main(int argc,char *argv[]) 
{ 

ifl(argc != 2) 


fprintf (stderr, "usage mqunlink <name>\n"); 
return -1; 
} 
int ret = mgq unlink (argv{[1]); 
if(ret != 0) 
{ 
fprintf (stderr, "mgq unlink failed (Ss) \n", 
strerror (errno) ); 
return -2; 
} 


return 0; 





Linux 下 POSIX 提 供 了 mqueue 类 型 的 虚拟 文件 系统 ， 可 以 通过 挂 载 ， 很 方便 地 使 用 ls 和 rm 来 列 出 或 删 
除 POSIX 消 息 队 列 。 


可 以 通过 如 下 命令 将 消息 队列 挂 载 到 文件 系统 : 





mount -t mqueue source target 





其 中 source 可 以 为 Ione，target 是 挂 载 点 。 比 如 可 以 通过 如 下 命令 挂 载 消 息 队 列 : 





mkdir /dev/mqueue 
mount -t mqueue none /dev/queue 








使 用 第 一 个 程序 编译 出 mqcreate 二 进 制程 序 ， 使 用 第 二 个 程序 编译 出 mqunlink 二 进 制程 序 ， 可 以 做 如 
下 试验 : 





./mqcreate /abcd 
11 /dev/mqueue 总 用 量 

















=IW======= 1 manu manu 80 3 月 


9 22:26 abed 
cat /dev/mqueue/abcd 
QSIZE:0 NOTIFY:0 SIGNO:0 NOTIFY PID:0 











可 以 看 出 ， 通 过 mqcreate 创 建 出 来 的 消息 队列 ， 可 以 通过 ls/dev/mqueue 来 查看 ， 甚 至 可 以 通过 
cat/dev/mqueue/queue_name 来 获取 消息 队列 的 信息 。 














11.2.2 ”消息 队列 的 属性 















































介绍 mq_open 函 数 时 兽 提 到 ， 第 四 个 参数 是 mq_attr 类 型 的 ， 表 示 消 息 队 列 的 属性 。 创 建 时 可 以 指定 消息 队列 的 属性 ，POSIX 消 息 队 列 也 提供 
了 mgq_setattr 函 数 来 改变 消息 队列 的 属性 。 





























在 继续 讨论 之 前 ， 首 先 需 要 了 解 消息 队列 有 哪些 属性 ，mq_attr 结 构 体 中 定义 了 以 下 成 员 。 











struct mq attr { 
long mq flags; 
long mq maxmsg; 
long mq msgsize; 
long mq _ curmsgs; 





这 个 结构 体 定义 在 <mqueue.h> 文 件 中 : 








-mq_flags: 0 或 设置 了 O_NONBLOCK。 









































-mq_maxmsg: 消息 队列 中 的 最 大 消息 个 数 。 
-mq_msgsize: 单条 消息 允许 的 最 大 字 贡 数 。 


-mq_curmsgs: 消息 队列 当前 的 消息 个 数 。 
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如 果 调 用 mq_open 函 数 创 建 POSIX 消 息 队 列 时 ， 第 四 个 参数 为 NULL， 那 么 将 使 用 默认 属性 。 可 以 使 用 如 下 代码 来 获取 默认 属性 : 


























虎 





int ret = mq getattr (mqd,&attr) 7 

if(ret !=0) 
fprintf (stderr, "failed to get attr(%d: %s)\n",errno,strerror (errno)); 
return 2; 


二 
fprintf (stdout, "the default mq maxmsg = %ld\nthe default mq _ msgsize = %ld\n", 
attr.mq maxmsg,attr.mq msgsize); 














其 输出 如 下 : 








the default mq maxmsg = 10 
the default mq msgsize = 8192 























从 输出 可 以 看 出 ， 默 认 情 况 下 ， 消 息 队列 的 最 大 消息 数 为 10， 单 条 消息 的 最 大 字 节 数 为 8192 字 节 。 



































其中 消息 队列 的 最 大 消息 数 的 默认 值 10 记 录 在 如 下 位 

















cat /proc/sys/fs/mqueue/msg default 
10 




















单条 消息 的 最 大 字 节 数 的 默认 值 8192 记 录 在 如 下 位 置 : 











cat /proc/sys/fs/mqueue/msgsize default 
8192 





消息 队列 中 只 能 存放 10 条 消息 ， 这 明显 太 少 了 ， 此 外 单条 消息 的 最 大 字 节 数 8192 可 能 也 无 法 满足 我 们 的 需要 。 因 此 创建 消息 队列 的 时 候 需 
要 定制 属性 ， 定 制 方法 如 下 所 示 : 

















attr.mq msgsize = atoi (argv 
mqd t mqd = mq open(argv[1 
if (mqd == -1) 


attr.mq maxmsg = atoi (argv[2]); 

[3] ， 

],O_RDNR1O_CREAT |O EXCL,S IRUSR|S IWUSR, &attr); 
fprintf (stderr, "failed to get mqueue (%d: %s)\n",errno,strerror (errno)); 


return 1; 


有 












































但 是 消息 队列 的 最 大 消息 数 和 单条 消息 的 最 大 字 节 数 并 不 能 被 随意 指定 。 它 受 限 于 多 个 控制 选项 。 
































对 于 普通 用 户 《 非 特权 用 户 ) 而 言 ， 内 核 提供 了 两 个 控制 选项 : 








cat /proc/sys/fs/mqueue/msg max 

10 

cat /proc/sys/fs/mqueue/msgsize max 
8192 









































这 两 个 值 分 别 是 最 大 消息 数 的 上 限 和 单条 消息 最 大 字 节 数 的 上 限 。 普 通用 户 在 定制 消息 队列 属性 的 时 候 不 能 超越 这 个 上 限 。 这 两 条 限制 是 
针对 普通 用 户 而 言 的 ， 对 于 特权 用 户 而 言 可 以 忽视 这 两 条 限制 。 
















































































很 明显 ， 这 个 上 限 值 并 不 大 ， 特 权 用 户 可 以 调整 这 两 项 的 值 ; 


























Sysctl -w fs.mqueue.msg max=4096 
fs.mqueue.msg max = 4096 

sysct1 -WwW fs.mqueue.msgsize max=65536 
fs.mqueue.msgsize max = 65536 


























但 是 不 能 随意 设置 上 限 值 ， 对 于 /proc/sys/fs/mqueue/msg_max， 系 统 提供 了 硬 上 限 HARD MSGMAX， 见 表 11-4。 









































表 11-4 消息 队列 最 大 消息 数 的 硬 上 限 








内 核 版 本 HARD_MSGMAX 
低 于 或 等 于 2.6.32 131072/sizeof (void* ) 
2.6.33 全 人 4 ( 32768 * sizeof (void *)/4) 
3.5 版 本 及 以 上 65536 
对 于 /proc/sys/fs/mqueue/msgsize _ max， 系统 也 提供 了 硬 上 限 ， 见 表 11-5。 





















































表 11-5 消息 队列 中 单条 消息 最 大 字 节 数 的 硬 上 限 


内 核 版 本 msgsize_max 系统 硬 上 限 
2.6.28 版 本 之 前 INT MAX 
2.6.28 版 本 至 3.4 版 本 1048576 ( 1MB) 
3.5 版 本 及 以 上 的 版 本 16777216 ( 16MB ) 该 值 对 特权 进程 也 有 效 























通过 调整 对 应 的 控制 选项 ， 可 以 让 消息 队列 容纳 更 多 的 消息 ， 或 者 让 每 条 消息 可 以 容纳 更 多 的 内 容 。 















































可 是 事实 上 ， 除 了 上 述 控制 选项 外 ， 还 存在 其 他 限制 。 如 果 调 整 msg_max 控 制 选项 到 4096， 调 整 msgsize_max 控 制 选项 到 65536 字 节 ， 那 么 可 
以 创建 出 能 容纳 4096 条 消息 ， 每 条 消息 的 最 大 长 度 为 64 字 节 的 消息 队列 ;也 可 以 创建 出 只 容纳 两 条 消息 ， 每 条 消息 最 大 长 度 为 65536 字 节 的 消息 
无 法 创建 出 既 可 以 容纳 4096 条 消息 ， 每 条 消息 的 最 大 长 度 又 为 65536 字 节 的 消息 队列 。 这 表明 除了 上 述 两 条 控制 外 ， 还 存在 其 他 限 




































































至 
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全 
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该 限制 就 是 介绍 mq_open 时 提 到 的 RLIMIT MSGQUEUE。RLIMIT MSGQUEUE 属 于 资源 限制 的 范畴 。 它 限制 了 用 户 可 以 在 POSIX 消 息 队 列 中 
分 配 的 最 大 字 节 数 。 注 意 不 是 单个 消息 队列 的 最 大 字 节 数 ， 也 不 是 一 个 进程 能 分 配 的 最 大 字 节 数 ， 而 是 该 用 户 创建 的 所 有 的 消息 队列 的 最 大 字 
节 数 。 如 果 新 建 消息 队列 会 导致 所 有 消息 队列 的 字 节 数 超出 此 限制 ， 那 么 调用 mq_open 函 数 时 会 返回 EMFILE 错 误 。 





























































































































© 注意 ”Robert Love 大 师 在 《Linux 系 统 编程 》 中 提 到 的 返回 ENOMEM 是 错误 的 。 








RLIMIT MSGQUEUE 默 认为 819200 字 节 ， 可 以 通过 如 下 指令 来 查看 : 

















ulimit -q 
819200 














我 曾经 遇 到 这 样 一 个 问题 ， 当 我 在 Ubuntu 12.04 上 创建 第 10 个 默认 属性 的 POSIX 消 息 队 列 时 ， 会 返回 EMFILE 错 误 ， 这 说 明 默 认 情 况 下 最 多 只 
能 创建 9 个 消息 队列 。 下 面 来 细 细 分 析 这 个 场景 。 






















































































默认 情况 下 ， 单 个 消息 队列 最 多 有 10 条 消息 ， 每 条 消息 的 最 大 字 节 数 为 8192。 这 就 意味 着 该 消息 队列 满载 的 时 候 ， 会 占用 81920 字 节 。 























按照 RLIMIT_MSGQUEUE 的 含义 ， 应 该 可 以 创建 10 个 消息 队列 ， 可 是 为 什么 却 只 能 创建 9 个 默认 属性 的 消息 队列 呢 ? 


















































原因 是 消息 队列 消耗 的 空间 ， 不 能 仅仅 计算 消息 体 〈payload) ， 还 要 考虑 额外 的 开销 。 可 以 从 内 核 的 mqueue_get_inode 函 数 中 找到 答案 。 











/*mq_msg_tblsz 是 额外 的 开销 





大 
/ 
mq msg tblsz = info->attr.mq maxmsg * sizeof (struct msg msg *) 
info->messages = kmalloc (mq msg tblsz, GFP KERNEL); 
if (!info->messages) IO 本 
goto out inode; 
/*mq_bytes 是 消息 队列 真正 消耗 的 空间 


大 
/ 
mq bytes = (mq msg tblsz + 
(info->attr.mq maxmsg * info->attr.mq msgsize)); 
spin lock(&mq lock); 
if (u->mq bytes + mq bytes < u->mq bytes || 
Uu->mq bytes + mq bytes > task rlimit(p, RLIMIT MSGQUEUE)) { 
spin unlock(&mq lock); 
/* mqueue evict inode() releases info->messages */ 
ret = -EMFILE; 
goto out inode; 














从 上 面 的 代码 不 难看 出 ， 一 个 消息 队列 消耗 的 总 空间 为 : 





bytes = (attr.mq msgsize + sizeof (struct msg msg*))*attr.mq maxmsg 

















因此 当 RLIMIT_MSGQUEUE 的 值 为 819200 字 节 时 ， 单 个 














户 是 无 法 创建 出 10 个 默认 属性 的 消息 队列 的 。 











© 注意 “上述 计 算 消息 队列 消耗 空间 的 计算 公式 仅仅 适用 了 











F 某 些 内 核 版 本 ， 并 不 能 当成 绝对 的 公式 。 对 于 不 同 的 内 核 版 本 ， 需 要 查看 
内 核 的 mqueue_get_inode 函 数 来 确定 。 对 这 个 话题 感 兴趣 的 可 以 参阅 内 核 开发 邮件 列表 
接 为 : https://lkml.org/lkml/2014/9/29/116 








Pp 的 Document POSIX MQ/proc/sys/fs/mqueue files 话 题 。 链 





要 想 




















以 通 





过 setrlimit 函 数 来 修改 。 


通过 ulimit 命 令 来 修改 ， 也 可 














让 消息 队列 中 容纳 足够 多 的 消息 ， 每 条 消息 也 足够 大 ， 那 就 需要 同时 修改 RLIMIT_MSGQUEUE 的 值 。 可 以 








消息 队列 创建 以 后 可 以 通 


划 

















过 调用 mq_setattr 来 修改 








属性 ， 相 关 接 口 定义 如 下 : 








#include <mqueue.h> 


int mq getattr (mqd t mqdes, struct mq attr *attr); 
int mq setattr (mqd t mqdes, struct mq attr *newattr, 
struct mq attr *oldattr); 





对 于 mq_maxmsg 和 mq_msgsize 这 两 个 属性 ， 在 消息 队列 创建 的 时 候 ， 就 已 经 确定 下 来 了 ， 
这 两 个 属性 。 





























虽然 提供 有 mq_setatt 函 数 ， 但 是 该 函数 并 不 能 修改 














该 函数 可 以 改变 的 属 拆 


E 只 有 第 


个 mq_flags， 即 可 以 通过 改变 O NONBLOCK 标 志 位 来 确定 是 否 置 位 。 
O_NONBLOCK 属 性 的 方法 如 下 : 















































其 他 的 属性 均 不 可 以 修改 。 改 变 
mq getattr (mqd, &attr); 
attr.mq flags |= 0O _NONBLOCK; /* 设 置 





〇 _NONBLOCK 属 性 


二 
/V/attr.mq_flags &=(~O_NONBLOCK) ; /* 取 消 


O_NONBLOCK 属 性 


家 
mq setattr (mqd, &attr, NULL) 





11.2.3 消息 的 发 送 和 接收 


1 .发 送 消 恩 














POSIX 消 息 队 列 发 送 消息 和 接收 消息 的 接口 都 很 容易 理解 ， 从 易 用 性 的 角度 来 讲 ， 它 们 要 优 于 
System V 消 息 队 列 的 对 应 接口 。 


发 送 消息 的 接口 定义 如 下 : 





#include <mqueue.h> 
int mq send(mqd t mgqdes, const char *msg ptr, 
size t msg len, unsigned msg prio); 





第 三 个 参数 msg len 表 示 消 息 体 的 长 度 ， 长 度 为 0 也 是 合法 的 ， 最 大 不 得 超过 mq _msgsize。 如 果 消 息 
体 太 大 ， 则 会 返回 失败 ， 并 置 errno 为 EMSGSIZE。 





第 四 个 参数 为 消息 的 优先 级 ， 是 一 个 非 负 的 整数 。 那 么 问题 就 来 了 ， 容 许 优先 级 最 大 为 多 少 ? 在 
Linux 中 ， 这 个 上 限 为 32768。 





#define MO PRIO MAX 32768 


如 果 消 息 队 列 已 满 ，mq _send 函 数 可 能 会 阻塞 。 如 果 设 置 了 O_NONBLOCK 标 志 位 ， 这 种 情况 下 
mq_send 函 数 会 返回 失败 ，errno 被 置 为 EBPAGAIN。 





2. 接 收 消息 


接收 消息 的 接口 定义 如 下 : 








ssize t mq receive (mgd_ t mqdes, char *msg ptr, 
size t msg len, unsigned *msg prio); 














对 于 POSIX 消 息 队 列 而 言 ， 总 是 取 走 优先 级 最 高 的 消息 中 最 先 到 达 的 那个 。 





第 二 个 参数 msg_ptr 指 针 用 于 存放 消息 体 的 内 存 缓冲 区 的 地 址 ， 第 三 个 参数 msg_len 是 该 内 存 缓冲 区 
的 大 小 。 因 为 消息 体 的 长 度 是 不 确定 的 ， 所 以 该 缓冲 区 的 大 小 不 得 小 于 最 大 消息 体 的 长 度 
(mq_msgsize) ， 和 否则 一 旦 消息 体 长 度 超过 缓冲 区 的 大 小 ， 就 会 失败 ， 并 返回 EMSGSIZE 错 误 。 如 何 获 
得 消息 队列 的 最 大 消息 长 度 ? 通过 mq _getattr 函 数 ! 














如 果 第 四 个 参数 msg_prio 不 是 NULL， 那 么 系统 就 将 取 到 的 消息 体 的 优先 级 复制 到 msg_prio 指 向 的 
整 型 变量 。 第 四 个 参数 如 果 为 NULL， 则 表示 压根 不 在 乎 消息 体 的 优先 级 。 


如 果 调 用 mq _ receive 函数 时 ， 消 息 队 列 中 并 没有 消息 ， 则 函数 陷入 阻塞 。 如 果 设 置 了 
O_NONBLOCK 标 志 位 ， 则 立即 返回 失败 ， 并 设置 errno 为 BAGIAN。 














POSIX 消 息 队 列 的 本 质 就 是 个 优先 级 队列 。 优 先 级 高 的 消 轧 总 是 被 优先 取出 。 从 这 个 角度 上 
看 ，System V 消 息 队 列 更 灵活 ， 它 可 以 让 各 个 进程 选取 自己 感 兴趣 的 消 居 。 








11.2.4 消息 的 通知 





对 于 System V 消 息 队 列 ， 当 消息 队列 里 面 有 消息 到 来 时 ， 消 息 队 列 却 无 法 通知 其 他 进程 来 取 。 对 于 
消息 队列 中 消息 的 消费 者 而 言 ， 只 有 两 条 路 径 : 

















:调用 msgrev 函 数 ， 阻 塞 于 此 ， 直 到 消息 队列 里 面 有 消息 。 








.调用 msgrev 函 数 时 设置 PC NOWAIT 标 志 位 ， 周 期 性 轮 询 。 





从 编程 的 角度 看 ， 期 待 有 这 样 一 种 机 制 来 解决 上 述 困境 : 空 的 消息 队列 一 收 到 消息 ， 就 给 相应 进 
程 发 出 通知 ， 被 通知 的 进程 收 到 通知 后 就 可 以 及 时 地 处 理 消 息 。 这 种 机 制 称 为 异步 通知 机 制 。POSIX 消 
四 队列 就 引入 了 这 种 机 制 。 




















POSIX 消 息 队 列 提供 了 两 种 异步 通知 的 方法 可 供 选 择 : 


产生 一 个 信号 





:创建 一 个 线程 来 执行 一 个 事先 指定 的 函数 。 


如 果 一 个 进程 非常 关心 POSIX 消 息 队 列 上 出 现 的 消息 ， 那 么 该 进程 可 以 通过 调用 mq_notify 函 数 来 表 
示 密 切 关 注 。 








#include <mqueue.h> 
int mq notify(mgqd t mqdes, const struct sigevent *sevp); 





mq_notify 函 数 的 含义 是 调用 进程 通过 该 接口 注册 到 消息 队列 ， 当 空 消息 队列 中 出 现 一 条 消息 时 ， 
消息 队列 就 会 通知 到 注册 进程 ， 也 可 以 通过 该 接口 注销 调用 进程 曾经 的 注册 。 手 册 中 英文 描述 更 加 准 
傅 : 


























mq notify() allows the calling process to register or unregister for delivery of 
an asynchronous notification when a new message arrives on th mpty messag 
queue referred to by the descriptor mqdes. 





关于 消息 通知 ， 有 以 下 几 个 注意 事项 : 





:只 能 有 一 个 进程 注册 到 特定 的 消息 队列 。 如 果 一 个 消 妃 队列 上 已 经 有 注册 进程 了 ， 那 么 后 续 调 用 
mq_notify 来 注册 的 进程 会 返回 EBUSY 错 误 。 





只 有 在 消息 进入 空 消息 队列 的 情况 下 ， 才 会 向 注册 进程 发 送 通知 。 如 果 注 册 时 ， 消 息 队 列 非 空 
那么 只 有 当 消 息 队 列 被 清空 后 ， 叉 有 一 条 消息 到 达 时 ， 才 会 发 出 通知 。 




















:消息 队列 向 注册 进程 发 出 通知 后 ， 会 删除 注册 信息 。 之 后 任何 进程 都 可 以 通过 调用 mq_notify 函 数 
来 注册 到 消息 队列 ， 并 接收 通知 了 。 














只 有 在 当前 不 存在 其 他 进程 因 在 该 队列 上 调用 mq _ receive 〈) 而 陷入 阻塞 时 ， 注 册 进 程 才 会 收 到 
消息 通知 。 否 则 阻塞 在 mq_receive〈) 上 的 进程 会 “ 截 胡 ”， 读 取 该 信息 ， 而 注册 进程 依然 保持 注册 状 


























ay 
O 


进程 可 以 通过 在 调用 mq_notify 函 数 时 传 入 一 个 值 为 NULL 的 sevp 参 数 来 撤销 自己 在 消息 队列 上 的 注 
册 信 息 。 




















前 面 讨 论 了 消息 通知 的 基本 流程 ， 但 是 当 消息 队列 满足 通知 的 条 件 时 ， 又 是 如 何 通知 到 注册 进程 
的 ? 

















mq_notifiy 函 数 的 关键 在 第 二 个 入 参 上 ， 其 结构 体 包含 如 下 参数 ， 知 记 不 清 成 员 变 量 ， 则 可 以 通过 
man sigevent 来 查看 手册 。 





union sigvalf{ 
int sigval int; 
void *sigval ptr; 
} 
struct sigevent { 
int sigev_notify; /* 决 定 采用 哪 种 通知 方法 ， 信 号 还 是 线程 


二 
int sigev_signo;  /* 用 于 信号 方式 ,决定 发 送 哪个 信号 


wh 
union sigval sigev_ value; /* 信 号 方式 和 线程 方式 都 有 其 独特 含义 


void (*sigev notify function) (union sigval); 
void *sigev notify attributes; 





结构 体 sigevent 的 第 一 个 成 员 sigev_notify 用 于 选择 采用 哪 种 方式 来 通知 注册 进程 ， 其 有 效 值 有 以 下 


三 个 : 

















:SIGEV_NONE: 当 消 息 到 达 空 的 消息 队列 时 ， 不 采取 任何 通知 行动 。 








-SIGEV_SIGNAL: 采用 发 送信 号 的 方式 通知 进程 。 








.SIGEV_THREAD: 通过 调用 segev_notify function 中 指定 的 函数 来 通知 进程 ， 就 如 同 在 一 个 新 的 线 
程 中 启动 该 函数 一 样 。 





下 面 将 分 别 介 绍 后 两 种 方法 。 


1. 信 号 通知 





如 果 采 用 信号 方式 (SIGEV_SIGNAL) ， 那 么 调用 mq_notify 的 进程 需要 约定 好 希望 收 到 哪 种 信号， 
其 实现 一 般 如 下 所 示 : 


struct sigevent sev; 

sev.sigev notify = SIGEV_ SIGNAL; 

sev.sigev signo = SIGUSR1; 

if (mq_notify (mqd, &sev) == -1) /*mqq 为 消息 队列 描述 符 


*/ 


/*error handler*/ 


} 





调用 mq_notify 函 数 的 进程 需要 考虑 该 如 何 处 理 随 时 可 能 到 来 的 信号 。 





最 容易 想到 的 方法 就 是 ， 在 信号 处 理 函 数 中 ， 调 用 mq_receive 函 数 ， 并 进一步 处 理 消息 。 很 不 幸 的 
是 ， 这 种 方法 行 不 通 。 第 


第 6 章 讲 信号 时 提 到 过 ， 大 多 数 函 数 都 不 是 异步 信号 安全 的 ，mq receive 函数 也 


不 是 异步 信号 安全 函数 。 更 何况 ， 还 要 在 信号 处 理 函 数 中 执行 复杂 的 逻辑 ， 这 就 如 同行 驶 在 暗礁 丛生 





























的 水 域 ， 很 容易 触礁 沉船 ， 这 种 做 法 是 不 明智 的 。 





等 待 信号 来 临 不 外 乎 有 以 下 三 种 方法 ; 





‘sigsuspend 
“sigwait 
‘signalfd 


《Linux/Unix 系 统 编程 手册 》 给 出 了 使 月 








日 sigsuspend 函 数 来 等 待 信号 并 处 理 消 息 的 一 个 例子 ， 而 这 里 
我 们 来 介绍 下 第 二 种 方法 ， 使 用 sigwait 函 数 来 等 待 信号 的 来 临 并 处 理 消 息 。 

















在 第 6 章 中 提 到 过 ，sigwait 函 数 的 引入 ， 解 决 了 信号 的 蜡 步 带 来 的 很 多 问题 。 可 以 说 这 个 函数 提供 
了 一 种 同步 的 方式 来 等 待 信号 的 降临 。 


#include <signal.h> 
int sigwait (const sigset 七 *set, int *sig); 














将 要 等 得 的 信号 放置 到 set 中 ，sigwait 函 数 调用 就 会 被 阻塞 ， 直 到 se 尺 合 中 的 茶 个 信号 处 于 未 决 状 
态 ，sigwait 函 数 才 会 返回 ， 信 号 的 值 记录 在 sig 指 针 指 向 的 整 型 变量 中 。 需 要 注意 的 一 点 是 ， 调 用 
sigwait 函 数 之 前 ，set 中 的 所 有 信号 都 要 被 阻塞 ， 否 则 结果 是 不 可 预知 的 。 




















以 SIGUSR1 为 例 ， 





SIGUSR1， 收 到 信 


mqd 七 mqd; 

struct mq attr attr ; 

sigset 七 newmask ; 

struct sigevent sigev; 

mqd = mq_ open (mq filename,O RDONLY|O NONBLOCK); 
mq getattr (mqd, &attr); 

buffer = malloc(attr.mq msgsize); 


/确保 


Duffez 足 够 大 


A 

sigemptyset (&newmask);; 

sigaddset (&newmask, SIGUSR1); 

sigprocmask (SIG BLOCK, &gnewmask,NULL) ; /* 阻 塞 等 待 的 信号 


大 
/ 
Sigev. Sigev | notify = = SIGEV SIGNAL; 
sigev.sigev signo = SIGUSRI; 

mq notify (mqd, &sigev); 

fo ( 


{ 





于 


sigwait (&newmask, &signo) ; /* 等 待 


SIGUSR1 信 号 


4 
if(signo == SIGUSR1) 


mq_notify (mqd, &sigev) ; /* 先 重新 注册 


notify 函 数 


i 


while( n = mq receive (mgd,buffer,attr.mgq msgsize,NULL) 


{ 


/*process the message in buffer*/ 
} 
if(errno != EAGAIN) 


/*some error happened*/ 


我 们 调用 mq_notify 函 数 ， 使 消息 
号 时 ， 去 消息 队列 中 取出 该 消息 ， 整 个 流程 如 下 : 


条 临 空 队列 时 ， 发 送信 号 SIGUSR1， 主 流程 等 待 





>= 0) 














要 注意 的 是 ，mq _notify 函 数 注册 之 后 ， 


日 发 出 信号 完成 使 命 ， 要 


续 使 用 这 种 通知 机 制 ， 








要 再 次 调用 mq_notify 函 数 重 新 注册 。 


使 用 sigsuspend 函 数 和 sigwait 函 数 虽 然 都 可 以 等 到 
明智 的 做 法 。 更 合理 的 做 法 是 使 用 signalfd 机 制 ， 











言 号 的 来 临 ， 但 是 也 阻塞 了 当前 进程 ， 这 并 不 是 


合 select、pool 或 epoll 等 多 路 复 用 的 接口 ， 实 现 真正 


的 事件 驱动 编程 。 


2. 通 过 线程 处 理 消 忆 





POSIX 消 息 队 列 提供 的 另外 一 种 方法 就 是 创建 线程 ， 执 行 预先 约定 的 函数 。 








在 使 用 中 ， 需 要 将 sigev.sigev_notify 设 置 成 SIGEV_THREAD， 同 时 设置 好 线程 应 该 执行 的 函数 ， 即 
将 sigev.sigev_notify_fonction 设 置 成 约定 好 的 函数 。 如 果 线 程 函数 需要 入 参 ， 则 可 以 将 任何 变量 的 地 址 
填 入 sigev.sigev_value.sival _ ptr 中 ， 到 达 传 递 参 数 的 目的 。 











创建 的 线程 具有 默认 的 属性 。 如 果 对 于 线程 有 特殊 的 要 求 ， 则 可 以 通过 如 下 方法 来 设置 : 














pthread attr 七 thread attr; 

pthread attr init(&thread attr); 

pthread attr setdetachstate(&atttr, PTHREAD CREATE DETACHED); 
Sigev.sigev notify attributes = &thread attr; 








整体 代码 流程 如 下 (示意 代码 ， 不 完整 〉: 





static void notify function (union sigval sv) 
{ 
struct mqd t *mqdp = sv.sival ptr: 


mq getattr (*mqdp, &attr); 
buffer = malloc(attr.mgq msgsize): 


/大 确保 


Duffer 足 够 大 


Ry 
notify setup (mqdp); /* 再 次 注册 


4 
while(n = mq recevie(*mqdp,buffer,attr.mq msgsize,NULL)>=0) 


/* 处 理 


ljbuffer 中 的 消息 体 


*/ 
} 
if(lerrno != EAGAIN) 


/* 发 生 错误 





类 


} 
free (buffer); 

} 

static void notify setup (mqd t* mqdp) 

{ 
struct sigevent sig ev; 
Sigev.sigev notify = SIGEV_ THREAD; 
Sigev.sigev notify function = notify function; 
Sigev.sigev notify _ attriputes = NULL; 
sigev.sigev value.sival ptr = mqdp; 
mq notify(*mqdp,*sigev); 


int main() 
mqd = mq_ open (mgqfilename,O RDONLY | O NONBLOCK); 
notify setup(&mqd); 
for(;;) 


{ 
} 


pause () ， 














in 


和 信号 通知 机 制 一 样 ， 一 旦 创建 线程 执行 完毕 ， 通 知 机 制 就 结束 了 ， 需 要 重新 调用 mq_notify 函 数 
来 注册 。 


11.2.5 LO 多 路 复 用 监控 消息 队列 
























































POSIX 消 息 队 列 的 通知 功能 或 许 在 其 他 Unix 平 台 上 非常 有 用 ， 但 是 在 Linux 平 台 下 用 处 并 不 大 ， 因 为 在 Linux 平 台 下 有 更 友好 、 更 强 
大 的 方法 。 
















































































在 Linux 系 统 中 ， 消 息 队列 描述 符 被 实现 成 了 文件 描述 符 ， 因 此 完全 可 以 使 用 MO 多 路 复 用 系统 调用 来 监控 消息 队列 。 这 种 方法 非 








1AYo 



































《Unix 网 络 编程 卷 2: 进程 间 通 信 》 的 5.6.6 节 给 出 了 一 个 例子 ， 如 何 使 用 select 来 监控 POSIX 消 息 队 列 。 由 于 在 某 些 平台 下 ， 消 息 
队列 描述 符 并 不 是 文件 描述 符 ， 所 以 不 能 直接 使 用 select。Stevens 大 师 给 出 的 方法 就 相当 地 绕 ， 有 具体 方法 如 下 。 











































































































首先 使 用 mq_notify 函 数 来 注册 ， 确 保 当 空 的 消息 队列 中 出 现 消息 时 ， 进 程 会 收 到 信号 SIGUSR1; 其 次 进程 打开 了 一 个 管道 ， 进 程 
调用 select 监 听 管 道 的 读 取 端 ;在 SIGUSR1 的 信号 处 理 函 数 中 负责 往 管道 的 写 入 端 写 入 一 个 字符 。 这 样 当 消息 降临 空 消息 队列 时 ， 整 
个 的 逻辑 流程 就 如 图 11-2 所 示 。 





































































































空 消息 队列 收 到 信号 通知 进程 执行 信号 处 理 函 数 负 责 监听 管道 的 select 
上 


一 条 消息 信号 处 理 函 数 向 管道 写 人 字符 函数 醒 来 ， 处 理 消 息 








图 11-2 APUE 中 监听 消息 队列 的 流程 









































该 方案 如 此 近 巴 绝 非 大 师 之 过 ， 在 操作 系统 不 支持 的 情况 下 ， 只 能 如 此 处 理 。 因 为 Linux 支 持 在 消息 队列 上 执行 select/poll/epoll， 
所 以 可 以 让 这 条 路 变 得 一 马 平川 (如 图 11-3 所 示 )。 


























消息 队列 收 到 监听 消息 队列 的 


电 队 列 区 select 了 辑 数 醒 来 
条 消息 处 理 消息 








现 








11-3 Linux 下 监听 消息 队列 的 流程 




















代码 形式 如 下 所 示 : 





mad = mq _open(argv[1],O RDONLY | O NONBLOCK); 
if (mqd == -1) 
{ 
fprintf (stderr,"failed to open mqueue (%d: $s)\n",errno,strerror (errno)); 
return 1; 
} 
mq getattr (mqd, &attr); 
buffer = malloc (attr.mq_ msgsize); 
FD ZERO(&rset); 
for (;;) 
FD _ SET (mqd, &rset); 
nfds = select (mqd+1, &rset, NULL,NULL, NULL); 
if (FD ISSET (mqd, &rset)) 
while((n = mq receive (mqd,buffer,attr.mgq msgsize,NULL)) >=0 ) 


/* 在 此 处 处 理 本 条 消息 


4 
} 
ifl(errno != EAGAIN) 


/* 发 生 错 误 ， 进 行 错误 处 理 


人 

















注意 上 面 的 例子 比较 简易 ， 仅 仅 是 监听 了 一 个 消息 队列 ， 根 据 实际 情况 ， 可 以 同时 监听 多 个 消息 队列 和 多 个 文件 。 只 需要 在 上 和 
代码 的 基础 上 打开 其 他 文件 或 消息 队列 ， 将 这 些 文件 描述 符 置 于 select 的 监控 之 下 ， 如 果 有 来 自 文件 描述 符 的 输入 (FD_ISSET 来 判 
断 ) ， 添 加 相应 的 处 理 函 数 即 可 。 






















































































这 条 特性 并 不 是 标准 



























































































































































E 规 定 的 ， 标 准 并 未 规定 将 消息 队列 描述 符 实现 为 文件 描述 符 ， 因 此 使 用 1/O 多 路 复 用 系统 调用 监控 消息 队列 
并 不 具备 可 移植 性 。 尽 管 如 此 ， 个 人 还 是 认为 本 条 性 质 是 POSIX 消 息 队列 最 
POSIX 消 息 队 列 带 来 了 压倒 性 的 优势 。 


























要 的 性 质 ， 和 System V 消 息 队 列 相 比 ， 本 条 性 质 给 


11.3 POSIX 信和 与 量 








POSIX 信 号 量 和 System V 信 号 量 的 作用 是 相同 的 ， 都 是 用 于 同步 进程 之 间 及 线程 之 间 的 操作 ， 以 达 
到 无 冲突 地 访问 共享 资源 的 目的 。 


在 前 面 介绍 System V 信 号 量 的 时 候 也 曾 介 绍 过 ，Edsger Dijkstra 提 出 了 PV 操作 。 所 谓 P 操 作 ， 代 表 荷 
兰 语 中 的 Proberen〔 意 思 是 尝试 ) ， 也 被 称 为 递减 操作 或 上 锁 操 作 。 在 POSIX 术 语 中 为 等 待 (wait) 。 
所 谓 V 操 作 代 表 荷 兰 语 单 次 Verhogen (意思 是 增加 ) ， 也 被 称 为 递增 操作 、 解 锁 操 作 和 发 信号 (signal) 
操作 。 在 POSIX 术 语 中 为 挂 出 (post)。 











POSIX 信 号 量 的 作用 和 System V 信 号 量 是 一 样 的 。 但 是 两 者 在 接口 上 有 很 大 的 区 别 : 








:POSIX 信 号 量 将 创建 和 初始 化 合 二 为 一 ， 这 就 解决 了 System V 中 可 能 出 现 竞 争 条 件 的 问题 。 





:POSIX 信 号 量 的 修改 信号 量 值 的 接口 (sem post 和 sem wait) ， 一 次 只 能 修改 一 个 信号 量 。 与 之 对 
应 的 SystemV 信 和 号 量 其 本 质 是 信号 量 集 ， 其 下 的 semop 函 数 一 次 可 以 修改 多 个 信和 号 量 。 











要 了 


:POSIX 信 号 量 的 修改 信号 量 值 的 接口 (sem post 和 sem wait) ， 一 次 只 能 将 信号 量 的 值 加 1 或 减 1。 


与 之 对 应 的 System V 信 和 号 量 的 semop 函 数 ， 能 够 加 上 或 减 去 一 个 大 于 1 的 值 。 














POSIX 信 号 量 并 没有 提供 一 个 等 待 信号 量变 为 0 的 接口 ， 而 System V 信 号 量 中 ，semop 函 数 则 提供 
了 这 样 的 接口 。 


:POSIX 信 号 量 并 没有 提供 UNDO 操 作 ， 而 System V 信 号 量 则 提供 了 这 样 的 操作 。 








从 表面 看 ，System V 信 号 量 的 能 力 完 胜 POSIX 信 号 量 ， 事 实 上 并 非 如 此 。System V 信 和 号 量 有 过 度 设 
计 之 嫌 ， 在 大 部 分 场景 下 ，System V 提 供 的 第 2、3 和 4 条 特性 都 没有 什么 用 处 ， 反 而 徒 增 接口 的 复杂 程 
度 。 而 POSIX 信 号 量 提供 的 接口 异常 清晰 ， 易 于 理解 和 使 用 。 





























POSIX 信 号 量 真正 比 System V 信 号 量 优越 的 地 方 在 于 ，POSIX 信 号 量 性 能 更 好 。 对 于 System V 信 号 
量 而 言 ， 每 次 操作 信号 量 ， 必 然 会 从 用 户 态 陷入 内 核 态 ， 可 以 想象 当 加 锁 和 解锁 操作 比较 频繁 的 时 
候 ， 时 间 上 的 开销 也 是 很 可 观 的 。POSIX 信 和 号 量 则 不 然 。 只 要 不 存在 真正 的 两 个 线程 争夺 一 把 锁 的 情 
况 ， 那 么 修改 信号 量 就 只 是 用 户 态 的 操作 ， 并 不 会 牵扯 到 内 核 。 在 竞争 并 不 激烈 的 情况 下 ，POSIX 的 性 


和 二 央 三 站 


能 要 远 远 高 于 System V 信 和 号 量 。 

















有 得 必 有 失 。 因 为 POSIX 信 号 量 不 会 每 次 操作 都 去 求助 内 核 ， 所 以 获得 了 性 能 上 的 提升 ， 但 却 因此 
而 失去 了 内 核 的 强大 后 援 。System V 信 和 号 量 支 持 UNDO 操 作 ， 当 用 户 进程 异常 消亡 之 后 ， 内 核 会 肩负 起 




















为 进程 还 债 的 责任 。 但 是 POSIX 信 和 号 量 却 没 有 这 个 特性 。 

















POSIX 提 供 了 两 类 信号 量 : 有 名 信号 量 和 无 名 信号 量 。 这 两 种 信号 量 的 本 质 都 是 一 样 的 ， 从 图 11-4 
可 以 看 出 ， 最 重要 的 sem_ wait 接 口 和 sem _ post 接口 也 都 是 一 样 的 。 如 此 说 来 ， 两 种 信号 量 有 何不 同 呢 ， 
各 自 应 用 在 哪些 场景 呢 ? 






















有 名 信号 量 无 名 信号 量 


sem open () sem init() 


sem wait() 
Sem trywait() 

sem post() 
sem getvalue() 





无 名 信号 量 有 名 信号 量 
sem ClLlose () 


sem destroy() sem unlink() 








图 11-4 有 名 信号 量 和 无 名 信号 的 接口 


无 名 信号 量 ， 又 称 为 基于 内 存 的 信号 量 ， 由 于 其 没有 名 字 ， 没 法 通过 open 操 作 直接 找到 对 应 的 信 
号 量 ， 所 以 很 难 直接 用 于 没有 关联 的 两 个 进程 之 间 。 无 名 信号 量 多 用 于 线程 之 间 的 同步 。 























有 名 信和 号 量 由 于 其 有 名 字 ， 多 个 不 相干 的 进程 可 以 通过 名 字 来 打开 同一 个 信号 量 ， 从 而 完成 同步 
操作 ， 所 以 有 名 信号 量 的 操作 要 方便 一 些 ， 适 用 范围 也 比 无 名 信和 号 量 更 三。 











11.3.1 创建、 打开、 关闭 和 删除 有 名 信号 量 








创建 或 打开 有 名 信号 量 ， 需 要 调用 sem_ open 函数 ， 其 接口 定义 如 下 : 





#include <fcntl.h> 

#include <sys/stat.h> 

#include <semaphore.h> 

Sem t *sem openl(const char xname int oflag); 

sem 七 *sem open (Const char *name, int oflag, 
mode t mode, unsigned int value); 


第 二 个 参数 oflag 标 志 位 支持 的 标志 包括 O CREAT 和 QO _EXCIL 标 志 位 。 如 果 带 了 O_CREAT 标 志 位 ， 
则 表示 要 创建 信号 量 。 











mode 表 示 创 建 的 新 信号 量 的 访问 权限 ， 标 志 位 和 open 函 数 一 样 ，mode 参 数 的 值 也 会 根据 进程 的 
umask 来 取 掩 码 。 





value 是 新 建 信号 量 的 初始 值 。 创 建 和 赋 初 值 都 是 由 一 个 接口 来 完成 的 ， 这 样 就 不 会 出 现 System V 
信和 号 量 可 能 出 现 的 初始 化 竞争 的 问题 了 。value 的 值 在 最 小 值 0 和 最 大 值 SEM_VALUE_ MAX 之 间 。SUSv3 
要 求 最 大 值 至 少 等 于 32767， 对 于 Linux 而 言 ， 这 个 限制 为 INT_MAX (在 Linux/x86 平 台 上 ， 该 值 是 
2147483647) 。 

















当 sem open 函数 失败 时 ， 返 回 SEM _ FAILED， 并 且 设 置 errno。 








注意 ， 不 要 尝试 创建 sem 结构 体 的 副本 ， 下 面 这 段 代 码 的 做 法 是 错误 的 : 





Sem t *sem p,sem dup; 
sem p = sem _ open (.… 





); 
sem dup = *sem ps;/* 非 法 操作 


二 
sem wait (&sem_ dup); 





上 面 定义 了 sem p 的 副本 sem_dup， 但 在 副本 上 执行 sem 的 相关 操作 ， 行 为 是 不 可 预知 的 ， 不 要 这 样 
使 用 。 切 记 ， 后 面 所 有 的 调用 都 要 用 通过 sem_open 返 回 的 sem_t 类 型 的 指针 来 进行 操作 ， 而 不 能 使 用 结 
构 体 的 副本 。 


























当 一 个 进程 打开 有 名 信和 号 量 时 ， 系 统 会 记录 进程 与 信号 的 关联 关系 。 调 用 sem_close 时 ， 会 终止 这 
种 关联 关系 ， 同 时 信号 量 的 进程 数 的 引用 计数 减 1。 关 闭 信和 号 量 的 接口 定义 如 下 : 

















#include <semaphore .h> 
int sem close (sem t *sem); 














进程 终止 时 ， 进 程 打 开 的 有 名 信号 量 会 自动 关闭 。 当 进程 执行 exec 系 列 函 数 时 ， 进 程 打 开 的 有 名 信 
号 量 会 自动 关闭 。 


























但 是 关闭 不 等 同 于 删除 ， 如 果 要 删除 信号 量 则 需要 调用 sem_unlink 函 数 ， 其 接口 定义 如 下 ;: 





#include <semaphore .h> 
int sem unilink(const char *name); 














将 有 名 信号 量 的 名 字 作 为 参数 ， 传 递 给 sem_unlink， 该 函数 会 负责 将 该 有 名 信和 号 量 删除 。 由 于 系统 
为 信号 量 维护 了 引用 计数 ， 所 以 只 有 当 打 开 信 号 量 的 所 有 进程 都 关闭 了 之 后 ， 才 会 真正 地 删除 。 





























11.3.2 ”信号 量 的 使 用 


言 号 量 的 使 用 ， 总 是 和 某 种 可 用 资源 联系 在 一 起 的 。 创 建 信 号 量 时 的 value 值 ， 其 实 指定 了 对 应 资 
源 的 初始 个 数 。 当 申请 该 资源 时 ， 需 要 先 调用 sem_wait 函 数 ; 当 发 布 该 资源 或 使 用 完毕 释放 该 资源 时 ， 
则 调用 sem_ post 函 数 。 





























sem_wait 函 数 用 于 等 待 信号 量 ， 它 会 将 信号 量 的 值 减 1， 其 接口 定义 如 下 : 





#include <semaphore.h> 
int sem wait(sem t *sem); 


如 果 调 用 sem_wait 函 数 时 ， 信 和 号 量 的 当前 值 大 于 0， 那 么 sem_wait 函 数 立 刻 返 回 。 和 否则 sem_wait 函 
数 陷入 阻塞 ， 待 信号 量 的 值 大 于 0 之 后 ， 再 执行 减 1 操作 ， 然 后 成 功 返回 














如 果 陷 入 阻塞 的 sem_wait 函 数 被 信号 中 断 ， 则 返回 -1， 并 且 置 errno 为 EINTR。 使 用 sigaction 注 册 信 
号 处 理 函 数 时 ， 无 论 是 否 使 用 了 SA_RESTART 标 志 位 ， 都 不 会 自动 重启 系统 调用 。 




















如 果 仅 仅 是 党 试 等 待 信号 量 ， 而 不 想 陷 入 阻塞 ， 则 可 以 调用 sem trywait 函 数 ， 其 接口 定义 如 下 : 





int sem trywait (Sem 七 *sem); 





sem_ trywait 会 尝试 将 信号 量 的 值 减 1， 如 果 信 和 号 量 的 值 大 于 0， 那 么 该 函数 将 信和 号 量 的 值 减 1 之 后 会 
立刻 返回 。 如 果 信 和 号 量 的 当前 值 为 0， 那 么 sem_ trywait 也 不 会 陷入 阻塞 ， 而 是 立刻 返回 失败 ， 并 置 errno 
为 EAGAIN。 








知 资 源 当 前 不 可 得 ， 那 么 sem_wait 调 用 就 可 能 会 陷入 无 限期 阻塞 ， 而 sem_ trywait 调 用 则 选择 立刻 返 
回 失败 ， 绝 不 阻塞 。 除 了 这 两 种 选择 ， 系 统 还 提供 了 第 三 种 选择 : 有 限期 等 待 ， 即 sem_timedwait 函 


sem timedwait 函 数 的 接口 定义 如 下 : 





int sem timedwait (Sem 七 xsSem const struct timespec *abs timeout); 








第 二 个 参数 为 一 个 绝对 时 间 。 可 以 使 用 gettimeofday 函 数 获取 到 structtimeval 类 型 的 当前 时 间 ， 然 后 
将 timeval 转 换 成 tmespec 类 型 的 结构 体 ， 最 后 在 该 值 上 加 上 想 等 待 的 时 间 。 或 者 调用 clock_gettime 函 
数 ， 直 接 获 得 timespec 结 构 体 类 型 的 变量 表示 当前 时 刻 ， 然 后 在 结构 体 上 加 上 想 等 待 的 时 间 ， 作 为 第 二 
个 参数 传 给 sem timedwait 函 数 。 

















如 果 超 过 了 等 待 时 间 ， 信 和 号 量 的 值 仍 然 为 0， 那 么 返回 -1， 并 置 errno 为 ETIMEOUT。 


2. 发 布 信号 量 




















sem_post 函 数 用 于 发 布 信号 量 ， 表 示 资 源 已 经 使 用 完毕 ， 可 以 归还 资源 了 。 该 函数 会 使 信号 量 的 值 
加 1 。 


sem post 接 口 定 义 如 下 : 


#include <semaphore .h> 
int sem Post (Sem t *sem); 

















如 果 发 布 信号 量 之 前 ， 信 和 号 量 的 值 是 0， 并 且 已 经 有 进程 或 线程 正 等 待 在 信号 量 上 ， 此 时 会 有 一 个 
进程 被 唤醒 ， 被 唤醒 的 进程 会 继续 sem_wait 函 数 的 减 1 操 作 。 如 果 有 多 个 进程 正 等 竺 在 信号 量 上 ， 那 么 
将 无 法 确认 哪个 进程 会 被 唤醒 。 















































当 函 数 调 用 成 功 时 ， 返 回 0， 失 败 时 ， 返 回 -1， 并 置 errno。 当 参数 sem 并 不 指向 合法 的 信号 量 时 ， 
置 errno 为 EINVAL; 当 信 和 号 量 的 值 超 过 上 限 〈 即 超过 INT_MAX) 时 ， 置 errno 为 EOVERFLOW。 








3. 获 取信 和 号 量 的 值 








sem_getvalue 函 数 会 返回 当前 信号 量 的 值 ， 并 将 值 写 入 sval 指 向 的 变量 ， 代 码 如 下 : 











#include <semaphore .h> 
int sem getvalue (Sem 七 xsSem int *sval); 








如 果 信 号 量 的 值 大 于 0， 含 义 自 不 必 说 ; 但 是 如 果 信号 量 的 值 等 于 0， 同 时 又 有 很 多 进程 或 线程 阻 
塞 在 信号 上 ， 那 么 应 该 返回 0 还 是 返回 一 个 负 值 一 一 其 绝对 值 等 于 等 待 进程 的 个 数 ? 看 起 来 后 者 更 有 意 
义 ， 因 为 从 该 值 可 以 获知 到 竞争 的 激烈 程度 ， 但 是 Linux 还 是 选择 返回 0。 


























当 sem getvalue 返 回 时 ， 其 返回 的 值 可 能 已 经 过 时 了 。 从 这 个 意义 上 讲 ， 该 接口 的 意义 并 不 大 。 








11.3.3 ”无 名 信号 量 的 创建 和 销毁 




















无 名 信号 量 ， 由 于 其 没有 名 字 ， 所 以 适用 范围 要 小 于 有 名 信号 量 。 只 有 将 无 名 信和 号 量 放 在 多 个 进 
程 或 线程 都 共同 可 见 的 内 存 区 域 时 才 有 意义 ， 人 否则 协作 的 进程 无 法 操作 信和 号 量 ， 达 不 到 同步 或 互 斥 的 
目的 。 所 以 一 般 而 言 ， 无 名 信号 量 多 用 于 线程 之 间 。 因 为 线程 会 共享 地 址 空间 ， 所 以 访问 共同 的 无 名 
信号 量 是 很 容易 办 到 的 事情 。 或 者 将 信号 量 创建 在 共享 内 存 内 ， 多 个 进程 通过 操作 共享 内 存 的 信号 量 
达到 同步 或 互 斥 的 目的 。 


















































1. 初 始 化 无 名 信和 号 量 


无 名 信号 量 的 初始 化 是 通过 sem_ init 函 数 来 完成 的 。 





#include <semaphore .h> 
int sem _ init (sem 七 xsSem int pshared, unsigned int value) 

















其 中 ， 第 二 个 pshared 参 数 用 于 声明 信号 量 是 在 线程 间 共享 还 是 在 进程 间 共 享 。0 表 示 在 线程 间 共 
享 ， 非 零 值 则 表示 信号 量 将 在 进程 间 共享 。 要 想 在 进程 间 共享 ， 信 号 量 必须 位 于 共享 内 存 区 域内 。 
































无 名 信号 量 的 生命 周期 是 有 限 的 ， 对 于 线程 间 共 享 的 信号 量 ， 线 程 组 退出 了 ， 无 名 信号 量 也 就 不 
复 存在 了 。 对 于 进程 间 共 享 的 信号 量 ， 信 号 量 的 持久 性 与 所 在 的 共享 内 存 的 持久 性 一 样 。 





























无 名 信号 量 初始 化 以 后 ， 就 可 以 像 操作 有 名 信和 号 量 一 样 操作 无 名 信号 量 了 。 


2. 销 毁 无 名 信和 号 量 


销毁 无 名 信号 量 的 接口 定义 如 下 所 示 : 








#include <semaphore .h> 
int sem destroy (sem 七 xSem) 




















sem_destroy 用 于 销毁 sem_init 函 数 初 始 化 的 无 名 信号 量 。 只 有 在 所 有 进程 都 不 会 再 等 待 一 个 信和 号 量 
时 ， 它 才能 被 安全 销毁 。 对 Linux 实 现 而 言 ， 省 略 sem_ destroy 函 数 ， 也 不 会 带 来 异常 。 但 是 为 了 安全 性 
和 可 移植 性 ， 还 是 应 该 在 合适 的 时 机 正常 销毁 信和 号 量 。 














11.3.4 信号 量 与 fotex 
































使 用 POSIX 信 号 量 ， 链 接 的 时 候 需 要 加 上 -lpthread， 而 不 是 -lrt。 由 此 可 以 看 出 POSIX 信 和 号 量 与 NPTL 线 程 库 渊 源 其 深 。 















































第 7 章 讲 线程 时 兽 提 到 过 ， 互 斥 量 是 建立 在 快速 用 户 空 间 互 斥 体 〈 英 文 全 名 为 但 st userspace mutex， 人 简称 futex) 基础 上 的 。POSIX 信 和 号 量 也 是 
架构 在 futex 基 础 之 上 的 。 












































快速 用 户 空 间 互 斥 体 ， 是 一 种 用 户 态 和 内 核 态 协同 工作 的 同步 机 制 。 同 步 的 进程 需要 一 段 共享 内 存 ，futex 变 量 就 位 于 这 段 内 存 之 中 。 当 进 
程 尝试 进入 或 退出 互 斥 区 时 ， 首 先 会 检查 共享 内 存 中 的 futex 变 量 ， 如 果 没 有 竞争 发 生 ， 则 原子 地 修改 futex 变 量 ， 无 须 执行 系统 调用 。 如 果 通 过 访 
问 fatex 变 量 的 值 发 现 有 竞争 发 生 ， 则 执行 相应 的 系统 调用 去 完成 相应 的 处 理 。 
































































































































I 


对 于 线程 间 同 步 ， 因 为 同一 个 进程 下 的 多 个 线程 共享 该 进程 的 地 址 空间 ， 所 以 同时 操作 某 个 futex 变 量 并 不 是 特别 难以 做 到 的 事情 。 如 果 是 
用 于 进程 间 的 同步 ， 则 首先 需要 一 块 内 存 空间 ， 而 且 要 让 多 个 进程 都 可 以 操作 该 内 存 空 间 ， 这 就 牵扯 到 共享 内 存 了 。 事 实 上 调用 sem_open 函 数 
来 创建 POSIX 信 和 号 量 时 ， 使 用 了 后 面 会 介绍 到 的 mmap， 并 在 多 个 进程 之 间 共 享 文件 的 内 容 。 





























































































































下 面 的 代码 摘自 glibc 的 sem open 函数 : 




















/* Create the initial file content. */ 
union 
{ 
sem t initsem; 
struct new sem newsem; 
} sem; 
/* 信 号 量 的 初始 值 为 


Value， 后面 会 写 入 文件 


六 
/ 
sem.newsem.value = value; 
sem.newsem.private = 0; 
sem.newsem.nwaiters = 07 
memset ((char *) &sem.initsem + sizeof (struct new sem), '\0', 
sizeof (sem t) - sizeof (struct new sem)); 


/3 


Sem 相 关 的 值 写 入 文件 ， 并 通过 


InmaP 喘 射 到 进程 的 内 存 中 


大 
/ 
if (TEMP FAILURE RETRY ( libc write (fd, &sem.initsem, sizeof (sem 七 ) )) 
== sizeof (sem t) > - 
/* Map the sem t structure from the file. */ 
&& (result = (sem t *) mmap (NULL, sizeof (sem t), 
PROT READ | PROT WRITE, MAP SHARED, 
fd, 0)) != MAP FAILED) 加 





每 创建 一 个 名 为 name 的 信号 量 ， 在 /devshm 下 就 会 多 出 一 个 名 为 semname 的 文件 。 该 文件 的 内 容 是 sem_t 结 构 体 : 














#if WORDSIZE == 64 
# define SIZEOF SEM T 32 
#else 
# define _SIZEOF SEM T 16 
#endif 二 
typedef union 
{ 
char size[ SIZEOF SEM T]; 
long int align; ~ 
} sem t; 




















HH 











在 x86 架 构 下 ，32 位 系统 里 ， 该 结构 体 的 大 小 是 16 字 节 ， 在 x86_64 架 构 下 ， 该 结构 体 的 大 小 是 32 字 节 。 事 实 上 ， 真 实 存放 的 内 容 是 new_sem 
结构 体 : 














union 

Sem 七 initsem; 

struct new sem newsem; 
} sem; 
/*new_sem 是 真正 使 用 的 结构 体 


可 


struct new_ sem 


unsigned int value;  /* 当 前 信号 量 的 值 


# 
int private; 
unsigned long int nwaiters; 


}; 

















下 面 创建 一 个 名 为 res_88 的 信号 量 ， 创 建 该 信号 量 时 ， 将 信号 量 的 值 初始 化 为 88。 代 码 如 下 所 示 : 











Sem t* sem = sem openl(argv[1],O RDWR|IO CREAT|O EXCL,S_ IRUSR|S_ IWUSR, 88); 





我 们 可 以 通过 查看 /dewshnysem.res 88 来 查看 该 信号 量 的 情况 : 








manu@manu-rush:~$ od -x /dev/shm/sem.res 88 
0000000 0058 0000 


0000 0000 0000 0000 0000 0000 
0000020 0000 0000 0000 0000 0000 0000 0000 0000 


0000040 





其 文件 内 容 的 含义 如 图 11-5 所 示 。 


value private nwaiters 


11-5 /dev/shm/sem.name 文 件 的 内 容 








从 输出 中 的 00580000 (0x58 等 于 88)〉 可 知 ， 当 前 信号 量 的 值 是 88。 





当 将 信号 量 的 值 减少 到 零 ， 并 且 有 两 个 进程 在 等 待 信号 量 时 : 


百 写 星 








manuemanu-rush:~$ od -x /dev/shm/sem.res 88 
0000000 0000 0000 0000 0000 0002 0000 0000 0000 


0000020 0000 0000 0000 0000 0000 0000 0000 0000 











输出 中 的 0002 0000 0000 0000 (0x02) 表示 当前 有 两 个 进程 等 待 在 该 信号 量 上 。 








其 他 进程 也 可 见 。 


























对 于 POSIX 信 号 量 而 言 ， 需 要 同步 的 进程 通过 mmap 将 文件 内 容 映 射 进 了 进程 的 地 址 空间 。 对 这 段 内 存 的 修改 ， 
































内 核 提供 了 futex 系 统 调用 ， 其 接口 定义 如 下 : 








#include <linux/futex.h> 

#include <sys/time.h> 

int futex(int *uaddr, int op, int val, const struct timespec *timeout, 
int *uaddr2; int val3)} 




















下 














第 一 个 参数 uaddr 是 用 户 空 间 的 一 个 地 址 ， 里 面 存放 的 是 整 型 变量 。 














用 于 存放 操作 命令 ， 最 基本 的 两 个 操作 命令 FUTEX_WAIT 和 FUTEX_WAKE。 





第 二 个 参数 op 
巴 进程 挂 到 uaddr 对 应 














也 址 存放 的 int 值 是 否 等 于 val， 如 果 是 ， 那 么 内 核 会 使 进程 陷入 休眠 ， 同 时 





当 op 是 FUTEX_WAIT 时 ， 会 原子 地 检查 uaddrj 


的 等 待 队列 上 。 





当 op 是 FUTEX_WAKE 时 ， 最 多 唤醒 val 个 等 待 在 uaddr 上 的 进程 。 





在 没有 竞争 的 条 件 下 ， 可 以 通过 实验 来 比较 下 System V 信 号 量 和 POSIX 信 号 量 的 效率 ， 见 表 11-6。 同 样 是 初始 化 一 个 信号 量 的 值 为 1!， 然 后 交 


替 执行 wait 和 post 操 作 各 100 万 次 ， 可 以 看 出 ，System V 信 和 号 量 花费 的 时 间 是 POSIX 信 和 号 量 的 40 多 倍 。 












































表 11-6 POSIX 信号 量 和 System V 信 号 量 在 无 竞争 情况 下 的 性 能 比较 


POSIX 信号 量 System V 信号 量 (UNDO) 


用 strace 统 计 系 统 调用 次 数 ， 可 以 看 到 System V 信 号 量 共 执 行 了 200 万 次 semop 系 统 调 用 ， 而 POSIX 信 号 量 只 有 两 次 fhtex， 事 实 上 ， 这 仅 有 的 两 
次 futex 系 统 调用 ， 也 与 sem post 和 sem_ wait 调用 无 关 。 



























































































































































$ time seconds usecs/call calls errors syscall 
0.86 0.000012 6 之 1 futex 
$ time seconds usecs/call calls errors syscall 
89.99 14.265818 村 2000000 semop 
网 上 有 些 文 章 认 为 sem post 无 论 是 否 存在 竞争 都 会 执行 fatex 系 统 调用 ， 很 明显 这 种 观点 是 错误 的 ， 通 过 简单 的 实验 不 难 验证 这 点 。 因 为 信号 
































量 的 数据 结构 中 记录 了 等 待 者 的 数量 ， 因 此 不 难 判断 是 否 需 要 执行 系统 调用 ， 来 唤醒 等 待 者 。 









































至 于 存在 竞争 的 情况 ， 在 互 斥 量 相关 的 章节 中 已 经 介绍 过 ， 这 里 就 不 再 更 述 。 














11.4 内 存 映 射 mmap 





消息 队列 和 信和 号 量 都 已 经 介绍 过 了 ， 按 照 正 常 的 逻辑 ， 本 节 应 该 介绍 POSIX 共 享 内 存 ， 为 什么 这 里 
却 要 介绍 内 存 映 射 mmap 呢 ? 











这 是 因为 内 存 映 射 mmap 是 POSIX 共 享 内 存 的 基础 ， 内 存 映 射 完 成 了 大 量 的 基础 性 工作 ， 临 门 一 脚 
交 给 了 共享 内 存 。 事 实 上 POSIX 共 享 内 存 也 要 和 mmap 配 合 使 用 。 不 理解 mmap 就 不 能 很 好 地 理解 POSIX 








更 重要 的 是 ， 纵 然 不 提 共 享 内 存 ，mmap 这 个 系统 调用 也 是 非常 重要 的 ， 其 重要 程度 远 远 超过 
POSIX 共 享 内 存 。 只 要 你 在 Linux 平 台 上 工作 ， 每 天 就 一 定 会 执行 无 数 次 的 mmap 系 统 调用 ， 不 管 是 直接 
地 还 是 间接 地 。 























当 你 执行 哪怕 是 最 简单 的 ls 命令 时 ，mmap 系 统 调用 在 背后 都 会 默默 地 帮 你 加 载 动 态 链接 库 ， 当 你 
调用 malloc 函 数 分 配 大 于 MMAP_THRESHOLD 大 小 〈 默 认 是 128KB) 的 内 存 时 ，mmap 系 统 调用 会 躲 在 
malloc 背 后 支撑 ;， 当 你 调用 pthread_create 创 建 线程 时 ，mmap 系 统 调 用 会 帮 你 分 配 好 线程 栈 ， 当 你 创建 


POSIX 信 号 量 时 ，mmap 会 默默 帮 你 开辟 一 段 空 间 存放 fatex 变 量 .…… 








可 能 迄今 为 正 你 从 未 在 代码 中 直接 使 用 mmap， 但 它 就 静 静 地 躺 在 那里 ， 对 你 的 帮助 不 增 也 不 减 。 


11.4.1 内 存 映射 概述 





























mmap 系 统 调用 的 作用 是 在 调用 进程 的 虚拟 地 址 空间 中 创建 一 个 新 的 内 存 映 射 。 根 据 内 存 背 后 有 无 实体 文件 与 之 关联 ， 映 射 可 以 分 成 以 下 两 
种 : 


























文件 映射 : 内 存 映 射 区 域 有 实体 文件 与 之 关联 。mmap 系 统 调 用 将 普通 文件 的 一 部 分 内 容 直 接 映射 到 调用 进程 的 虚拟 地 址 空间 。 一 旦 完成 映 
射 ， 就 可 以 通过 在 相应 的 内 存 区 域 中 操作 字 节 来 访问 文件 内 容 。 这 种 映射 也 被 称 为 基于 文件 的 映射 。 






































:匿名 映射 : 匿名 映射 没有 对 应 的 文件 。 这 种 映射 的 内 存 区 域 会 被 初始 化 成 0。 















































一 个 进程 映射 的 内 存 可 以 与 其 他 进程 中 的 映射 共享 物理 内 存 。 所 谓 共享 是 指 各 个 进程 的 页 表 条 目 指向 RAM 中 的 相同 分 页 。 如 图 11-6 所 示 。 























进程 A 页 表 


物理 内 存 


映射 区 域 的 页 表 项 











进程 B 页 表 


映射 区 域 的 页 表 项 








图 11-6 ”进程 内 存 共享 映射 





这 种 内 存 映射 的 共享 ， 会 在 以 下 两 种 情况 下 发 生 : 














:通过 fork， 子 进程 继承 了 父 进程 通过 mmap 映 射 的 副本 。 

















“多 个 进程 通过 mmap 映 射 了 同一 个 文件 的 同一 个 区 域 。 






































无 论 映 射 背 后 有 无 实体 文件 与 之 关联 ， 这 个 进程 之 间 共 享 映射 的 特性 都 是 非常 有 用 的 。 我 们 知道 ， 进 程 的 虚拟 地 址 空间 是 彼此 隔离 的 ， 一 
个 进程 不 能 直接 操作 另 一 个 进程 虚拟 地 址 空间 中 的 内 存 。 但 是 mmap 系 统 调 用 给 出 了 两 个 办 法 ， 让 多 个 进程 可 以 共享 一 片 内 存 区 域 。 















































看 到 第 一 种 方式 ， 即 通过 fork 子 进程 继承 父 进程 通过 mmap 映 射 的 副本 ， 大 家 的 心中 可 能 会 隐隐 有 种 不 安 。 第 4 章 曾 提 到 过 ， 虽 然 子 进程 找 贝 
了 父 进程 的 内 在， 但 是 父子 进程 的 页 表 并 不 是 始终 都 指向 同一 物理 内 存 的 ， 一 旦 父子 进程 中 有 一 个 尝试 修改 内 存 的 内 容 时 ， 内 核 就 不 得 不 发 起 
写 时 复制 ， 分 配 新 的 物理 内 存 。 从 此 父子 进程 分 道 扬 镀 ， 彼 此 再 也 看 不 到 对 方 对 内 在 的 改动 。 



























































对 于 进程 malloc 出 来 的 内 存 ， 栈 上 的 变量 的 确 如 此 ，fprk 之 后 父子 进程 并 不 是 共享 同一 块 映射 。 但 是 通过 mmap 系 统 调用 创建 的 内 存 映 射 却 可 
以 做 到 进程 之 间 共 享 同一 个 内 存 映射 。 当 然 进 程 之 间 要 不 要 共享 映射 也 是 可 以 选择 的 ， 这 取决 于 该 映射 是 私有 了 映射 还 是 共享 映射 。 








































































































“私有 了 映射 “MAP_PRIVATE)〉: 在 映射 内 容 上 发 生 的 变更 对 其 他 进程 不 可 见 。 对 于 文件 映射 而 言 ， 变 更 不 会 同步 到 底层 文件 中 。 对 映射 内 
容 所 做 的 变更 是 进程 私有 的 。 事 实 上 ， 内 核 使 用 了 写 时 复制 技术 来 完成 这 个 任务 。 未 对 映射 内 容 进 行 修改 操作 时 ， 页 面 仍 然 是 共享 的 。 一 旦 有 
进程 试图 修改 其 中 一 个 分 页 的 内 容 时 ， 内 核 首先 会 为 该 进程 创建 一 个 新 的 分 页 ， 并 将 需要 修改 的 分 页 中 的 内 容 拷贝 到 新 分 页 中 。 








































































































共享 映射 “MAP_SHARED) : 在 映射 内 容 上 发 生 的 所 有 变更 ， 对 所 有 共享 同一 个 映射 的 其 他 进程 都 可 见 。 对 于 文件 映射 而 言 ， 变 更 会 同步 
到 底层 的 文件 中 。 很 明显 ， 共 享 映射 是 用 于 进程 间 通 信 的 。 










































































内 存 映 射 根据 有 无 文件 关联 ， 分 成 文件 与 匿名 ; 根据 映射 是 否 在 进程 间 共享 ， 分 成 私有 和 共享 。 这 两 个 维度 两 两 组 合 ， 内 存 映 射 共 分 成 4 种 
类 型 ， 其 各 自 的 用 途 如 表 11-7 所 示 。 
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表 11-7 ”内存 映射 的 分 类 及 用 途 


映射 类 型 
变 件 匿 名 
内 存 映 射 IO， 进 程 间 共享 内 存 进程 间 共 享 内 存 


私有 根据 文件 内 容 初始 化 内 存 内 存 分 配 


下 面 ， 我 们 开始 介绍 如 何 利 用 mmap 接 口 ， 实 现 这 四 种 不 同 的 内 存 映射 。 


















































11.4.2 ”内 存 映 射 的 相关 接口 


mmap 函 数 的 接口 定义 如 下 : 








#include <sys/mman.h> 
void *mmap (void *addr, size t length, int prot, int flags, 
int fd otf t wtftoet}? 











这 个 函数 的 参数 比较 多 。 其 中 亿 、offset 和 llength 这 三 个 参数 指定 了 内 存 映射 的 源 ， 即 将 和 对 应 的 文件 ， 从 offset 位 置 起 ， 将 长 度 为 length 的 内 容 
映射 到 进程 的 地 址 空间 。 



























































对 于 文件 映射 ， 调 用 mmap 之 前 需要 调用 open 取 到 对 应 文件 的 文件 描述 符 。 









































第 一 个 参数 addr 用 于 指定 将 文件 对 应 的 内 容 映射 到 进程 地 址 空间 的 起 始 地 址 。 一 般 来 讲 为 了 可 移植 性 ， 该 参数 总 是 指定 为 NULL， 表 示 交 给 
内 核 去 选择 合适 的 位 置 。 



































第 三 个 参数 prot 用 于 设置 对 内 存 映 射 区 域 的 保护 ， 它 的 合法 值 及 其 售 义 如 表 11-8 所 示 。 












































表 11-8 mmap 调 用 中 prot 的 合法 值 及 其 含义 





prot 说 明 
PROT EXEC 映射 的 内 容 可 以 执行 
PROT READ 映射 的 内 容 可 以 读 取 
PROT_WRITE 映射 的 内 容 可 以 修改 
PROT NONE 映射 的 内 容 不 可 访问 






































flags 参 数 用 于 指定 内 存 映 射 是 共享 映射 还 是 私有 了 映射， 也 用 于 指定 内 存 映 射 是 文件 映射 还 是 匿名 映射 。flags 可 选 的 标志 位 及 含义 如 表 11-9 所 

















表 11-9 mmap 调 用 中 flags 可 选 的 标志 位 及 含义 





标 志 位 说 明 
MAP SHARED 请 求 创 建 共 享 映 射 
MAP _ PRIVATE 请 求 创 建 私有 映射 
MAP _ ANONYMOUS 请 求 创 建 匿名 映射 ，fd 参数 必须 是 -1 








其 中 调用 mmap 函 数 时 ，MAP SHARED 和 MAP _ PRIVATE 标志 位 ， 两 者 必须 指定 一 个 。 








SS 


flags 中 男 一 个 可 选 的 标志 位 是 MAP_FIXED。 如 果 指 定 了 该 标志 位 ， 那 么 表示 函数 调用 者 铁 了 心地 要 把 内 容 映 射 到 对 应 的 地 址 上 。 这 种 情况 
下 ，addr 一 般 要 求 按 页 对 齐 。 如 果 内 核 无 法 映射 文件 到 认 ， 则 调用 失败 。 如 果 地 址 和 长 度 指定 的 内 存 区 域 和 已 有 映射 有 重 登 部 分 ， 那 
么 重 登 区 的 原始 内 容 将 被 丢弃 ， 然 后 填 入 新 的 内 容 。 使 用 该 选项 需要 非常 了 解 进程 的 地 址 空间 ， 和 否则 不 建议 使 用 。 
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需要 注意 的 是 mmap 系 统 调用 的 操作 单元 是 页 。 参 数 addr 和 offset 都 必须 按 页 对 齐 ， 即 必须 是 页 面 大 小 的 整数 倍 。 在 Linux 下 ， 页 面 大 小 是 4096 
字 节 ， 该 值 可 以 通过 getconf 命 令 来 获取 到 : 
























































getconf PAGESIZE 
4096 









































对 于 编程 接口 ，Linux 提 供 了 sysconf 函 数 来 获取 到 相关 配置 项 的 值 : 





#include <unistd.h> 
long sysconf (int name); 




















对 于 获取 页 面 大 小 而 言 ， 可 以 通过 如 下 代码 获取 到 页 面 的 大 小 : 












































long pagesize = sysconf(_SC PAGESIZE); 



























































在 进程 的 地 址 空间 里 ， 映 射 区 域 总 是 页 面 的 整数 倍 。 但 是 有 些 时 候 ，mmap 传 递 的 length 值 并 非 页 面 的 整数 倍 ， 比 如 文件 映射 时 ， 文 件 的 大 小 
或 要 映射 进 内 存 的 区 域 并 非 页 面 的 整数 倍 ， 这 时 候 ，mmap 会 按照 页 面 的 大 小 向 上 取 整 ， 多 出 来 的 内 存 区 域 〈 最 后 一 个 有 效 字 节 到 映射 区 域 边 
界 ) 会 填充 0。 
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映射 区 域 的 起 始 地 址 ， 如 果 失 败 ， 则 返回 MAP FAILED， 并 置 errno。 




















卫 





当 mmap 调 用 成 功 时 ， 则 返 



























































如 果 不 再 需要 对 应 的 内 存 映射 了 ， 可 以 调用 munmap 函 数 ， 解 除 该 内 存 映 射 : 











#include <sys/mman.h> 
int munmap (void *addr, size t length); 




















xl 
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其 中 addr 是 mmap 返 回 的 内 存 映射 的 起 始 地 址 ，length 是 内 存 映 射 区 域 的 大 小 。 执 行 过 munmap 后 ， 如 果 继 续 访问 内 存 映 射 范围 内 的 地 址 ， 那 
么 进程 会 收 到 SIGSEGV 信 号 ， 引 发 段 错误 。 需 要 注意 的 是 ， 关 闭 对 应 文件 的 文件 描述 符 并 不 会 引发 munmap。 

























































































如 果 创 建 内 存 映 射 时 flags 中 带 上 了 MAP_PRIVATE 标 志 位 ， 那 么 解除 该 内 存 映 射 时 ， 调 用 进程 对 内 存 映 射 的 所 有 改动 都 会 被 丢弃 。 
























































介绍 完 基 本 接口 ， 下 面 将 分 别 介绍 4 种 不 同 的 映射 ， 以 及 它们 的 应 用 场景 。 


11.4.3 ”共享 文件 映射 


1. 共 享 文件 映射 的 建立 和 使 用 











创建 共享 文件 映射 的 步骤 如 下 所 示 。 














1) 打开 文件 ， 获 取 文 件 描 述 符 乌 ， 这 一 步 是 通过 open 来 完成 的 。 





2) 将 文件 描述 符 作为 和 参数 ， 传 给 mmap 函 数 。 


整个 步 又 如 下 面 的 伪 代 码 所 示 : 


fd = open(...); 

adqr = mmap(..., MAP_ SHARED, fd, ...); 
close (fd); /* 可 选 ， 可 以 关闭 ， 也 可 以 不 关闭 

wy 














第 1) 步 打 开 文 件 时 设置 的 权限 必须 要 和 mmap 系 统 调用 需要 的 权限 相 匹 配 。 上 其 体 来 讲 就 是 : 





-打开 时 ， 必 须 允 许 读 取 ， 即 0O_RDONLY 和 O_RDWR 人 至少 要 指定 一 个 。 











-mmap 调 用 时 ， 如 果 prot 参 数 中 指定 了 PROT WRITE， 并 且 flags 中 指定 了 MAP SHARED， 那 么 打开 时 ， 必 须 带 有 


O_RDWR 标志 位 。 








open 时 需要 注意 ， 并 非 所 有 的 文件 都 支持 mmap 操 作 ， 比 如 管道 文件 就 不 支持 mmap 操 作 。 
































mmap 完 成 之 后 关闭 文件 描述 符 并 不 会 导致 内 存 映 射 被 解除 ， 因 此 ， 在 没有 其 他 需要 的 情况 下 ， 可 以 调用 close 关 





闭 文件 。 


























刻 同步 到 底层 的 磁盘 文件 中 ， 这 可 能 需 
们 都 要 修改 内 存 映射 的 部 分 内 容 ， 这 种 











但 在 某 些 场景 下 ， 后 续 操 作 还 会 用 到 文件 描述 符 ， 
需 要 对 文件 描述 符 包 调用 fync 或 faatasync; 再 比如 多 个 进程 间 共享 内 存 映 射 ， 它 
情况 可 以 通过 文件 的 记录 锁 (fentl 函 数 的 F SETLKW 命 令 ) 来 同步 进程 的 操 

















因此 不 宜 关 闭 文件 。 比 如 进程 需要 将 对 内 存 映射 所 做 的 修改 立 





























作 。 因 此 ， 建 立 共享 文件 映射 之 后 是 否 关 闭 文件 描述 符 ， 需 要 根据 实际 情况 来 做 决定 。 















































mmap 这 个 接口 容易 产生 的 一 个 误解 是 ， 调 用 mmap 时 ， 真 的 已 经 把 文件 对 应 区 域 的 内 容 读 取 到 了 内 存 的 对 应 位 
置 。 事 实 上 并 非 如 此 ，mmap 仅 仅 是 建立 了 两 者 之 间 的 关联 。 当 第 一 次 读 取 映射 区 的 内 容 或 修改 映射 区 的 内 容 时 ， 会 








引发 缺 页 中 断 (page fault) ， 这 时 候 才 会 真正 | 























地 将 文件 


的 内 容 加 载 到 内 存 的 对 应 位 置 。 


























当 mmap 调 用 成 功 之 后 ， 共 享 映射 在 进程 地 址 空间 中 的 位 置 ， 以 及 和 对 应 文件 的 关系 如 图 






































11-7 所 示 。 


进程 地 址 空间 


栈 
文件 映射 区 域 


未 初始 化 数据 段 


已 初始 化 数据 段 


代码 段 








YY 一 -一 
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< 一 抽 尾 示 蜂 开 朵 


文件 描述 符 亿 对 应 的 文件 


图 11-7 进程 地 址 空间 中 映射 区 域 和 文件 的 关系 


文件 是 有 长 度 的 ， 所 以 正常 情况 下 offset 和 length 参 数 应 该 遵循 一 定 的 限制 ，offset 应 小 于 文件 的 长 度 ， 并 且 
offsettlength 也 应 小 于 文件 的 长 度 。 很 有 意思 的 是 ，mmap 函 数 并 不 检查 offset 和 lsize 定 义 的 区 域 是 否 在 文件 的 范围 之 
内 。 示 例 代 码 如 下 : 


























#define MB 


1024*1024) 


ret = fstat(fd,&stat buf); 
if (ret < 0 ) 
{ 


} 
off t filesize = stat buf.st size ; 
off t offset = (filesize % PAGESIZE == 0) ? \ 
和 filesize : (filesize/PAGESIZE + 1)*PAGESIZE; 

mmap base = mmap (NULL, stat buf.st size+MB, PROT READ,MAP SHARED, fd,offset); 
if (mmap base == MAP FAILED) 后 
{ 

fprintf (stderr, "failed to mmap (%s)\n",strerror (errno)); 

ret = 3} 

goto out ; 
} 











A| 





上 面 的 代码 中 ， 将 文件 结尾 之 后 的 1M 字 节 映 射 到 进程 的 地 址 空间 ， 映 射 的 区 域 和 文件 完全 没有 交集 。 在 这 种 情 
况 下 ，mmap 也 不 会 因 offset 和 length 参 数 而 返回 MAP_FAILED， 而 是 正常 地 返回 。 












































© 注意 “此 处 说 的 是 不 检查 offset 和 ]length 定 义 的 范围 是 否 在 文件 长 度 范围 之 内 ， 并 不 是 说 不 检查 offset 和 size 
的 值 。mmap 调 用 要 求 offset 必 须 为 系统 分 页 的 整数 倍 ， 这 个 限制 始终 存在 。 如 若 offset 的 值 不 是 系统 分 页 的 整数 
党 ，mmap 会 返回 MAP FAILED， 并 置 errno 为 EINVAL。 






























































尽管 mmap 不 检查 对 应 区 域 是 否 落 在 文件 的 长 度 范 围 之 内 ， 但 是 这 并 不 意味 着 随意 建立 的 映射 也 能 正常 使 用 。 使 
用 共享 文件 映射 需要 谨慎 ， 和 否则 很 容易 触发 错误 。 















































最 容易 想到 的 一 种 错误 就 是 没有 映射 某 区 域 却 强行 访问 ， 而 且 无 论 该 区 域 是 否 落 在 文件 的 长 度 范围 以 内 《如 图 
11-8 所 示 ) 。 这 种 访问 会 引发 段 错 误 ， 产 生 SIGSEGV 信 号 。 该 信号 的 默认 动作 是 进程 终止 并 产生 核心 转 储 文件 。 
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< 一 一 映射 的 尺寸 产生 SIGSEGV 的 引用 一 一 > 
0 4095 4096 8191 10139 
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< filesize 一 





图 11-8 访问 内 存 映射 的 常见 错误 (1) 








这 种 错误 是 一 目 了 然 的 。 但 是 如 果 调 用 mmap 时 length 不 是 系统 分 页 大 小 〈4KB) 的 整数 倍 时 ， 情 况 就 会 稍稍 有 些 
复杂 ， 如 图 11-9 所 示 。 文 件 的 长 度 为 10KB， 但 是 调用 mmap 时 ， 将 文件 的 前 5KB 映 射 到 了 进程 的 地 址 空间 。 这 种 情况 
下 ， 真 正 映射 的 大 小 会 被 向 上 舍 入 成 系统 分 页 的 整数 倍 ， 对 于 这 个 例子 而 言 ， 虽 然 mmap 调 用 指定 了 5KB， 但 是 真实 
映射 了 8KB 的 大 小 。 用 户 访 问 mmap 返 回 基 地 址 偏 移 8KB 之 内 的 内 存 地 址 ， 都 不 会 触发 SIGSEGV 信 号 。 访 问 基 地 址 偏 移 
8KB 之 后 的 地 址 ， 才 会 触发 IGSEGV 信 号 。 












































另外 一 种 错误 是 访问 的 映射 地 址 虽然 在 mmap 映 射 的 内 存 区 域 之 内 ， 但 并 不 在 文件 长 度 的 范围 以 内 如 图 11-10 所 
示 ) ， 这 种 情况 会 导致 SIGBUS 信 号 的 产生 ， 该 信号 的 默认 动作 也 是 进程 终止 并 产生 核心 转 储 文件 。 这 种 错误 之 所 以 
会 出 现时 因为 mmap 并 不 会 检查 offset 和 size 定 义 的 区 域 是 否 落 在 文件 长 度 范围 以 内 。 既 然 建立 映射 的 时 候 不 检查 ， 那 么 
真正 访问 对 应 内 存 地 址 的 时 候 ， 就 可 能 触发 错误 。 
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映射 文件 
filesize > 


图 11-9 访问 内 存 映 射 的 常见 错误 (2) 
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< 产生 SIGBUS 的 引用 ->|<- 产生 SIGSEGV 的 引用 一 > 
二 映射 的 尺 十 > 
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<————— filesize 


图 11-10 访问 内 存 映射 的 常见 错误 〈3 ) 

















这 种 错误 也 是 很 明显 的 。 但 是 当 文件 的 大 小 不 是 系统 分 页 整数 倍 时 ， 也 会 带 来 一 定 的 特殊 情况 ， 如 图 11-11 所 
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图 11-11 访问 内 存 映 射 的 常见 错误 〈4) 








尽管 文件 的 长 度 是 3KB， ee 4KB~8KB 这 个 范围 自 不 必 说 ， 超 出 了 文 
件 的 范围 ， 访 问 时 一 定 会 触发 SIGBUS 信 号 。 但 是 比较 挠 头 的 是 3KB~4KB 这 个 范围 的 内 存 。 因 为 这 个 范围 已 经 不 在 文 
件 的 长 度 范围 之 内 了 ， 却 又 和 文件 的 有 效 映射 同 处 一 个 页 面 。 这 种 情况 下 人 允许 访问 ， 而 且 不 会 触发 SIGBUS 信 号 。 至 
于 要 访问 8KB 之 后 的 内 存 ， 那 已 经 是 尝试 访问 映射 范围 之 外 的 内 存 了 ， 会 触发 上 一 种 错误 ， 即 产生 SIGSEGV 信 号 






































第 一 种 情况 即 访问 映 射 范围 之 外 的 内 存 属于 典型 的 作 死 小 能 手 的 行为 。 但 是 很 有 意思 是 ， 有 时 候 访问 本 映射 范围 
之 外 的 内 存 却 不 一 定 会 触发 SIGSEGV。 原 因 是 mmap 区 域 可 能 存在 多 个 内 存 映 射 ， 虽 然 超 出 了 本 想 访 问 的 映射 的 范 
围 ， 却 牌 打 正 着 访问 到 了 相 邻 的 内 存 了 映射。 注意， 这 种 情况 并 不 值得 窃 喜 ， 而 是 更 糟糕 ， 因 为 程序 已 经 不 是 按照 预 设 
的 逻辑 在 运行 了 ， 继 续 运 行 很 可 能 会 在 某 个 不 可 预知 的 地 方 衣 溃 ， 这 就 增 大 了 排查 问题 的 难度 。 

























































































第 二 种 错误 更 需要 程序 员 小 心 。 表 面 看 只 要 调用 mmap 时 小 心 谨慎 ， 不 主动 出 么 峨 子 〈 即 映射 超出 文件 长 度 范围 
的 内 存 区 域 ) ，SIGBUS 信 和 号 就 不 会 出 现 。 其 实则 不 然 。 如 果 内 存 映射 在 使 用 过 程 中 ， 调 用 truncate 或 fruncate 将 文件 截 
断 ， 那 么 访问 文件 真实 长 度 之 外 的 区 域 ， 就 会 触发 SIGBUS 信 号 (如 图 11-12 所 示 )〉 。 因 为 共享 文件 映射 始终 和 文件 相 
关联 ， 因 此 这 种 情况 要 小 心 防范 。 
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映射 文件 





二 一 filesize 一 一 > 
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人 truncate 
映射 文件 < 
| filesize | 被 截断 一 一 一 > 








图 11-12 truncate 文 件 引起 SIGBUS 信 号 的 产生 


共享 文件 映射 的 用 途 


























共享 文件 映射 主要 用 于 两 个 方面 : 操作 文件 和 进程 间 通 信 。 
































Linux 提 供 了 read、write、lseek 等 操作 文件 的 系统 调用 ， 通 过 这 些 接口 可 以 操作 文件 。 共 享 文件 映射 给 出 了 另外 一 
种 操作 文件 的 方法 。 

















共享 文件 映射 将 文件 的 内 容 映 射 到 了 进程 的 地 址 空间 。 对 应 区 域 中 的 内 容 来 源 于 文件 ， 对 映射 内 容 所 做 的 修改 ， 
都 会 自动 反应 到 文件 上 ， 内 核 会 负责 将 修改 最 终 同 步 到 底层 的 块 设备 。 因 此 共享 文件 映射 区 域 的 内 存 ， 就 等 同 于 对 文 
件 的 读 写 。 












































访问 过 的 文件 页 面 ， 很 可 能 还 会 继续 访问 。 不 同 进程 很 可 能 会 访问 同一 文件 页 面 。 如 果 每 次 访问 文件 的 内 容 ， 都 
要 操作 底层 块 设 备 ， 那 性 能 就 会 很 差 。 因 此 现代 的 操作 系统 都 提供 了 文件 缓存 ，Linux 也 不 例外 。Linux 提 供 了 页 高 速 
缓存 〈Page Cache， 也 称 页 缓存 ) 用 以 减少 对 磁盘 的 访问 。 
































在 大 部 分 情况 下 ， 应 用 程序 都 会 通过 页 高 速 缓存 来 读 写 文件 。 当 读 取 文件 的 某 一 部 分 内 容 时 ， 内 核 首 先 会 从 页 高 
速 缓存 中 查找 所 读 取 的 数据 是 否 存在 对 应 的 页 面 ， 如 果 请 求 的 页 面 不 在 页 高 速 缓存 之 中 ， 那 么 内 核 就 会 负责 分 配 页 面 
并 添加 到 页 高 速 缓存 中 ， 然 后 从 磁盘 上 读 取 对 应 的 数据 来 填充 它 。 如 果 物 理 内 存 足够 大 ， 空 闲 页 面 足够 多 ， 那 么 该 页 
将 长 期 保留 在 页 高 速 缓存 中 ， 使 得 其 他 进程 访问 该 页 数据 时 不 需要 再 访问 磁盘 。 当 应 用 程序 向 文件 号 入 时 ， 会 直接 修 
改 页 高 速 缓存 中 的 数据 ， 但 是 并 不 会 立刻 写 入 磁盘 ， 而 是 将 该 页 标记 成 脏 页 ， 由 内 核 负 责 在 合适 的 时 机 将 脏 页 回 写 到 


磁盘 中 。 



































































































































调用 read 也 好 ， 调 用 write 也 罢 ， 事 先 都 要 准备 用 户 空 间 缓 冲 区 buffsr， 如 图 11-13 所 示 。 读 取 时 ， 将 读 到 的 内 容 复 
制 到 该 buffer 中 ; 写 入 时 ， 再 将 buffer 中 的 内 容 写 入 文件 中 。 
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11-13 read 和 write 都 需要 用 户 空 间 缓冲 区 























对 于 read 和 write 接口 而 言 ， 姑 且 不 论 磁盘 与 页 高 速 缓存 之 间 如 何 交 互 ， 页 高 速 缓存 和 用 户 空间 缓冲 区 之 间 的 数据 
传输 是 不 可 避免 的 。 但 是 如 果 使 用 mmap 来 操作 文件 ， 则 不 需要 这 次 复制 。mmap 对 共享 文件 映射 的 操作 ， 直 接 作 用 在 
页 高 速 缓存 上 ， 节 省 了 一 次 数据 传输 。 






































这 是 不 是 意味 使 用 mmap 来 操作 文件 要 比 使 用 read/write 的 性 能 更 好 呢 ? 大 家 很 容易 产生 这 种 想法 ， 但 这 种 想法 有 
些 想当然 。 随 着 硬件 的 发 展 ， 内 存 拷贝 消耗 的 时 间 已 经 极 大 地 降低 了 ， 可 是 mmap 访 问 文件 内 容 ， 会 引起 缺 页 中 断 
(page fault) 。 相 对 于 内 存 找 贝 而 言 ， 缺 页 中 断 的 开销 更 大 ， 加 上 创建 内 存 映射 、 解 除 内 存 映射 及 更 新 硬件 内 存 管理 
单元 的 翻译 后 备 缓冲 器 CTLB) 的 开销 ， 大 部 分 情况 下 《〈 不 考虑 刻意 构造 的 场景 ) ，mmap 的 性 能 反而 要 低 于 read 和 






























































write。 


Et 


共享 文件 映射 的 第 二 个 用 途 是 进程 间 通 信 。 进 程 的 地 址 空间 是 彼此 隔离 的 ， 一 个 进程 一 般 不 能 直接 访问 另 一 个 进 


程 的 地 址 空间 。 通 过 共享 文件 映射 ， 两 个 进程 的 映射 区 域 指 向 了 同一 个 物理 内 存 《〈 即 前 面 提 到 的 页 高 速 缓存 ) ， 这 就 


给 进程 间 通 信 提 供 了 可 能 ， 如 图 11-14 所 示 。 如 果 两 个 进程 的 共享 文件 映射 都 源 自 同一 个 文件 的 同一 个 区 域 ， 那 么 一 
个 进程 对 映射 区 域 的 修改 ， 对 于 另外 那个 进程 是 立刻 可 见 的 ， 同 时 内 核 会 负责 在 合适 的 时 机 将 修改 同步 到 底层 文件 。 


之 所 以 能 够 做 到 这 点 ， 是 因为 两 个 映射 区 域 的 对 应 分 页 都 指向 了 同一 个 页 高 速 缓存 〈Page Cache) ， 下 一 小 节 将 会 介 


















































绍 内 核 的 相关 实现 。 


进程 A 页 表 


物理 内 存 








打开 文件 
映射 区 域 的 页 表 项 






进程 B 页 表 文件 的 映射 区 域 








映射 区 域 的 页 表 项 


图 11-14 ”进程 通过 共享 文件 映射 共享 物理 内 存 








有 于 同步 对 共享 内 存 








所 有 的 共享 内 存 都 会 遇 到 的 问题 是 同步 。 无 论 是 System V 信 号 量 还 是 POSIX 信 号 量 ， 都 可 以 月 
的 操作 。 除 此 以 外 ， 记 录 锁 也 比较 适用 于 操作 共享 文件 映射 。 


fem 函数 提供 了 记录 锁 的 功能 ， 和 flock 函 数 提供 的 文件 锁 功 能 相 比 ，fentl 提 供 的 记录 锁 可 以 提供 更 细 粒 度 的 控 
锁定 的 是 整个 文件 ， 无 法 锁定 文件 的 某 个 区 域 。fentl 提 供 的 锁 可 以 锁定 文件 的 某 











制 。flock 函 数 提供 的 锁 是 粗放 型 锁 ， 
个 区 域 ， 如 图 11-15 所 示 ， 这 样 就 减少 了 因 竞 争 而 陷入 阻塞 的 概率 ， 从 而 提高 了 性 能 。 
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图 11-15 ”记录 锁 可 对 文件 的 特定 区 域 上 锁 


人 ent 函数 接口 的 定义 如 下 所 示 : 





#include <unistd.h> 
#include <fcntl.h> 
int fcntl(int fd, int cmd, ... /* arg */ ); 





其 中 与 记录 锁 相关 的 cmd 为 : 
:F_SETLKW: 尝试 锁定 文件 的 对 应 区 域 。 如 果 该 区 域 已 经 被 锁定 ， 则 陷入 阻塞 。 


:F_SETLK: 尝试 锁定 文件 的 对 应 区 域 。 如 果 该 区 域 已 经 被 锁定 ， 则 立刻 返回 -1。 


:F_GETLK: 仅仅 是 查询 锁 的 信息 ， 并 不 会 真正 地 对 某 区 域 加 锁 。 




















当 执行 加 锁 相 关 操作 时 ， 需 要 ) 





到 flock 结 构 体 ， 代 码 如 下 : 











struct flock { 


short 1 type; short 1 whence; off t 1 start; off t 1 len; pid t 1 pid; 


} 





其 中 1_type 用 于 指定 锁 的 类 型 ， 


:F RDLCK: 读 锁 





1] whence 的 含义 和 ]seek 函 数 的 入 


SEEK_CUR 和 SEEK_END。1_whence 参 数 结合 1_start 和 1 len 参 数 ， 定 义 了 文件 的 某 个 区 域 。 





入 三 个 参数 whence 的 含义 一 样 ， 表 示 如 何 解 释 人 1 











以 及 指定 解锁 操作 ， 其 合法 值 及 其 含义 如 下 : 


























届 移 量 ， 




















使 用 fent 对 文件 的 某 个 区 域 加 锁 解 锁 的 方法 如 下 示例 代码 所 示 : 


对 





























SEEK SET、 





struct flock fl1; 

int ret; 

f1.1 type = F WRLCK; 
£1.] whence = SEEK SET; 
fl1.1 start = 0; 

£1.1 len = 100; 

/* 对 文件 对 应 区 域 加 锁 


4 
ret = fcentl (fd,F SETLKW, &f1); 
/* 访 问 或 修改 


[0,99] 范围 内 的 文件 内 容 


*/ 


/* 对 文件 对 应 区 域 解锁 


*/ 
£1.1 type = F_UNLCK; 
ret = fentl (fd,F SETLK, gf1); 




















开 ， 以 及 更 细 粒 度 、 更 灵活 的 控制 。 


© 注意 ”flock 和 fentl 都 属于 劝告 式 锁 (Advisory Lock) ， 如 果 同 步 的 进 






























































锁 ， 就 能 起 到 同步 的 作用 ; 但 是 如 果 进 程 无 视 劝 告 式 锁 的 存在 ， 不 遵循 游戏 规则 ， 不 申请 锁 直 接 操作 文件 或 文人 











个 区 域 ， 内 核 也 不 会 阻止 这 种 操作 。 





3. 共 享 文件 映射 的 内 核实 现 

















对 于 共享 文件 映射 而 言 ， 最 大 的 谜团 























程 遵循 游戏 规则 ， 操 作 之 前 先 申请 


通过 上 面 的 讨论 可 以 看 出 ，fentl 提 供 的 记录 锁 非 常 适 用 于 同步 共享 文件 映射 的 操作 。 可 以 轻易 地 做 到 读 写 请 求 分 




















F 的 某 


是 : 进程 地 址 空间 彼此 独立 ， 互 不 干扰 ， 可 是 多 个 进程 通过 mmap 映 射 同一 





文件 的 同一 区 域 时 ， 却 指向 了 同一 物理 页 面 ， 修 改 彼此 可 见 。 内 核 是 如 何 做 到 的 ? 

















前 面 已 经 提 到 过 ， 答 案 是 通过 页 高 速 缓存 。 在 追踪 mmap 内 核实 现 之 前 ， 首 先 来 简单 介绍 下 页 高 速 缓存 。 























引入 页 高 速 缓存 的 目的 是 为 了 性 能 。 现 在 访问 的 文件 的 某 个 页 面 ， 将 来 可 能 还 会 再 访问 。 如 果 不 将 页 面 缓存 进 内 
存 ， 那 么 每 次 读 取 文 件 ， 就 都 不 得 不 操作 慢 速 的 块 设备 ， 这 会 极 大 地 影响 性 能 。 











页 高 速 缓存 该 如 何 组 织 多 个 页 面 ， 以 便 在 需要 时 可 以 快速 定位 到 这 些 缓存 页 面 呢 ? 对 于 单个 文件 来 说 ， 有 些 文件 
系统 支持 TB 级 别 的 文件 (比如 ext4 文 件 系统 就 已 经 支持 16TB 的 单个 文件 了 ) ，4KB 一 个 页 面 的 情况 下 ， 页 面 的 数目 是 
巨大 的 。 如 果 不 能 高 效 地 组 织 页 面 ， 那 么 花费 在 查找 页 面 上 的 时 间 就 可 能 会 很 长 ， 届 时 纵然 页 面 已 经 在 缓存 中 ， 也 会 
因 查 找 缓存 页 面 太 慢 而 导致 性 能 的 急剧 恶化 。 内 核 使 用 了 基数 树 (radix tree〉 来 解决 这 个 难题 ， 如 图 11-16 所 示 。 







































































只 要 找到 文件 对 应 的 基数 树 的 根 ， 就 可 以 快速 定位 到 与 文件 对 应 的 页 面 〈 如 果 它 在 页 高 速 缓存 中 的 话 ) 上 。 现 在 
问题 就 转变 成 了 : 当 进 程 操作 文件 时 ， 如 何 快速 找到 与 文件 对 应 的 基数 树 。 



































对 于 这 个 话题 ， 毛 德 操 老爷 子 在 《Linux 内 核 情景 分 析 》 一 书 的 5.6 节 中 有 高 屋 建 领 的 分 析 。 内 核 文 件 层 有 三 个 核 
心 的 数据 结构 : file、dentry 和 inode。 虽 然 三 种 数据 结构 都 可 以 通过 各 种 指针 来 跳 转 ， 找 到 与 文件 对 应 的 页 高 速 缓存 ， 
但 是 inode 是 和 页 高 速 缓存 关系 最 密切 的 数据 结构 。struct file 数 据 结构 是 进程 层面 的 概念 ， 提 供 的 是 目标 文件 的 一 个 上 
下 文 信息 。 对 于 同一 个 文件 ， 不 同 进程 可 以 在 该 文件 上 建立 不 同 的 上 下 文 ， 甚 至 同一 个 进程 也 可 能 因 多 次 打开 文件 而 
建立 起 多 个 上 下 文 。 换 名 话说， 数据 结构 struct file 和 实体 文件 并 不 是 一 对 一 的 关系 ， 而 是 多 对 一 的 关系 。dentry 结 构 
体 虽 不 是 进程 层面 的 概念 ， 但 是 dentry 和 实体 文件 也 不 是 一 对 一 的 关系 ， 通 过 文件 连接 ， 可 以 为 已 存在 的 文件 建立 别 
名 。 只 有 inode 结 构 最 适合 和 文件 的 页 缓存 关联 ， 因 为 inode 和 实体 文件 是 一 对 一 的 关系 。 
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图 11-16 通过 基数 树 加 速 页 面 查找 

















图 11-17 给 出 了 内 核 中 文件 与 页 缓存 相关 的 数据 结构 。 从 图 11-17 不 难看 出 ， 当 进程 通过 文件 系统 接口 (read/write 
等 ) ， 不 难 找到 与 文件 对 应 的 inode。Linux 内 核 引 入 了 地 址 空间 address_space 这 个 数据 结构 来 管理 页 高 速 缓存 。inode 
中 的 i_ mmaping 成 员 变 量 指向 对 应 的 address_space 结 构 体 。 不 论 多 少 个 进程 通过 文件 系统 API 来 操作 文件 ， 也 不 论 多 少 
个 进程 通过 mmap 建 立 共享 文件 映射 来 操作 文件 ， 同 一 个 文件 只 对 应 一 个 address_space 结 构 体 。 通 过 该 数据 结构 就 能 找 
到 与 页 高 速 缓存 对 应 的 基数 树 ， 进 而 找到 对 应 的 缓存 页 (如 果 存 在 的 话 〉。 


































































































通过 图 11-17 可 以 很 清晰 地 看 出 ， 当 通过 文件 系统 接口 进行 读 写 时 ， 如 何 找到 与 文件 对 应 的 缓存 页 面 。 但 是 mmap 
内 存 映射 区 域 和 页 高 速 缓存 如 何 建 立 联系 却 并 不 明晰 。 下 面 我 们 跟踪 mmap 系 统 调用 的 实现 来 一 探究 竟 。 

















调用 mmap 函 数 ， 进 入 内 核 之 后 首先 会 执行 到 arch/x86/kernel/sys_x86_64.c 中 的 如 下 函数 : 


file operations 


SEEUCE 
file 











address space 


基数 树 


page tree 


口 口 口 口 口 口 


图 11-17 文件 与 页 缓存 相关 的 数据 结构 



































SYSCALL DEFINE6 (mmap, unsigned long, addr, unsigned long, len, 
unsigned long, prot, unsigned long, flags, 
unsigned long, fd, unsigned long, off) 

















该 函数 非常 简单 ， 把 绝 大 部 分 工作 都 委托 给 了 内 核 的 sys_mmap_pgoff 函 数 。 该 函数 定义 在 mm/mmap.c 中 ， 其 原型 
声明 如 下 : 








~ 





SYSCALL DEFINE6 (mmap pgoff, unsigned long, agddr, unsigned long, len, 
unsigned long, prot, unsigned long, flags, 
unsigned long, fd, unsigned long, pgoff) 





这 个 函数 是 分 析 mmap 实 现 的 起 点 。 而 该 函数 将 大 部 分 工作 都 委托 给 了 do_mmap_pgoff。 该 函数 的 总 体 流程 如 图 11- 
18 所 示 。 










do mmap pgoff 


get unmapped area 


mmap_region 


file->f op->mmap (file,vma) 















图 11-18 内核 do_mmap pgoff 调 用 关系 





内 核 为 了 管理 进程 的 地 址 空间 ， 引 入 了 虚拟 内 存 区 域 (virtual memory area，VMA) 的 数据 结构 。 














vm_area_struct 结 构 体 描述 了 进程 地 址 空间 内 一 个 独立 的 内 存 范围 ， 如 图 11-19 所 示 。 当 通过 mmap 函 数 创 建 一 个 共 
享 文件 映射 〈 当 然 不 仅仅 是 共享 文件 映射 ) 的 时 候 ， 内 核 就 会 为 进程 分 配 一 个 新 的 vm_area_struct 结 构 体 。 每 一 个 
vm_area_struct 都 对 应 进程 地 址 空间 中 的 唯一 一 个 内 存 区 间 。 其 中 成 员 变 量 vm_start 指 向 区 间 的 开始 地 址 〈vm_start 本 身 
属于 对 应 内 存 区 间 ) ，vm end 指向 内 存 区 间 的 结束 地 址 〈vm end 本身 不 属于 对 应 内 存 区 间 ) ，vm end 减 去 vm _start 的 
值 即 为 内 存 区 间 的 长 度 。 对 于 共享 文件 映射 而 言 ， 该 长 度 为 调用 mmap 时 指定 的 length 向 上 取 整 为 页 面 大 小 的 整数 倍 。 
























































vm_area_struct 结 构 体 中 的 vm_flags 成 员 变 量 记 录 的 是 该 内 存 区 域 的 VMA 标 志 位 。 该 标志 位 记录 了 对 应 内 存 区 域 的 
一 些 属性 。 比 如 VM_READ 标 志 位 表示 对 应 的 页 面 可 读 取 ; VM_WRITE 标 志 位 表示 对 应 的 页 面 可 写 ，VM_EXEC 标 志 
位 表示 对 应 的 页 面 可 执行 ，VM_LOCKED 表 示 对 应 的 页 面 被 锁定 ， 等 等 。 




















vm area struct 进程 地 址 空间 


vm_mm 















vm_end 





vm start 








vm page prot 





struct mm struct 




































task struct | vm flags 
mmap 
1 vm area struct RE 
eR 一 一 mmap 区 域 
mm vm_mm 
vm end 
pgd | wn | 





vm start 
vm page prot 






















数据 段 
vm area struct 
vm_mm 文本 段 









vm ena 












vm start 











vm page prot 






vm flags 








图 11-19 进程 地 址 空间 与 VMA 

















如 果 虚 拟 内 存 区 域 和 文件 相关 联 ， 那 么 vm _area_struct 结 构 体 中 的 vm file 成 员 变 量 就 指向 与 文件 对 应 的 struct file 结 
构 。 通 过 该 指针 ， 虚 拟 内 存 区 域 就 可 以 和 文件 发 生 关 联 。 








另外 一 个 很 重要 的 成 员 变量 是 vm_ops。 该 成 员 是 一 个 指针 ， 指 向 与 内 存 区 域 相关 的 操作 函数 。 











struct vm operations struct { 


int (*fault) (struct vm area struct *vma, struct vm fault *vmf); 
int (*page mkwrite) (struct vm area struct *vma, struct vm fault *vmf); 








因为 vm_area_struct 是 一 个 通用 的 数据 结构 ， 可 以 代表 任意 类 型 的 内 存 区 域 ， 因 此 不 同 的 VMA 就 有 不 同 的 操作 函 
数 ，vm_ops 也 就 指向 了 不 同 的 操作 函数 集合 。 




















VMA 操 作 函 数 集合 中 的 fault 函 数 用 于 应 对 这 种 场景 : 访问 的 页 面 并 没有 出 现在 物理 内 存 中 ; 而 page_mkwrite 用 于 
































应 对 页 面 为 只 读 ， 应 





j 程 序 却 尝试 写 入 的 情况 。 这 两 个 函数 都 会 被 缺 页 中 断 处 理 程 序 调 用 ， 以 处 理 不 同 的 情景 。 





Np 





下 面 以 主流 的 ext4 文 件 系 统 为 例 ， 下 整个 流程 。ext4 文 件 系 统 中 inode 的 i_ fop 注 册 成 ext4_file_operations。 





ext4_file_operation 的 定义 位 于 fs/ext4/file.c 中 ， 其 中 与 mmap 相 关 的 操作 函数 定义 如 下 : 





const struct file operations ext4 file operations = { 
-mmap = ext4 file mmap, 
} 








当 mmap 系 统 调用 在 mmap_region 中 执行 fle->f op->mmap (file，vma)〉 时 ， 执 行 的 就 是 ext4_file mmap 函 数 。 因 此 
对 于 ext4 文 件 系统 而 言 ， 文 件 映射 的 调用 路 径 就 变 成 了 如 图 11-20 所 示 的 路 径 。 


do mmap pgoff 


get unmapped area | 


mmap_ region 


file-=>f op->mmap (file,vma) 





























ext4 file mmap 





图 11-20 内核 do_mmap _pgoff 的 调用 关系 (2) 





该 函数 异常 简单 ， 简 单 到 我 不 介意 将 全 函数 都 贴 在 这 里 











static int ext4 file mmap (struct file *file, struct vm area struct *vma) 
{ 

struct address space *mapping = file->f mapping; 

if (!mapping->a ops->readpage) 

return =ENOEXEC; 

file accessed (file); 

vma->vm ops = &ext4 file vm ops; 

vma->vm [flags |= VM CAN |] NONLINEAR; 

return 0; 





这 个 ext4_file map 函数 仅仅 安装 了 一 个 内 存 区 操作 函数 ， 即 把 vma 的 vm_ops 指 针 指 向 了 ext4_file_ vm ops。 





static const struct vm operations struct ext4 file vm ops = { 
‘fault = filemap fault, 
.page mkwrite = ext4 page mkwrite, 

}; 











注意 整个 mmap 调 用 的 过 程 中 并 没有 对 文件 的 大 小 做 过 判断 。 换 言 之 ， 哪 怕 文 件 的 大 小 只 有 100 个 字 节 ，mmap 仍 
然 可 以 将 文件 映射 到 1MB 的 内 存 空间 。 下 面 的 示例 代码 中 ， 尽 管 映 射 了 比 文件 的 大 小 还 要 多 1MB 的 空间 ， 但 是 mmap 
调用 依然 会 成 功 。 














/省略 了 


error handler*/ 

#define MB 1 (1024*1024) 

fd = open(argv[1],O RDONLY); 

ret = fstat(fd,&stat buf); 

mmap_base = mmap (NULL, stat buf.st size+MB 1,PROT READ,MAP SHARED, fd,0); 
if (mmap base == MAP FAILED) 





























mmap 之 后 ， 尽 管 进程 的 虚拟 地 址 空间 内 已 经 有 一 块 内 存 区 域 和 文件 相对 应 ， 但 内 核 并 没有 将 文件 的 内 容 加 载 到 


内 存 区 域 。 将 虚拟 内 存 区 域 vma 的 vm_ops 指 向 ext4_file vm ops 实 例 ， 其 实 是 埋 下 了 伏笔 。 一 旦 将 来 需要 访问 映射 
的 页 面 ， 尽 管 物理 内 存 中 没有 ， 但 依然 可 以 依靠 YMA 操 作 函 数 集 里 的 对 应 函数 来 处 理 这 个 和 危机。 





jx 
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知 乎 上 有 一 个 提问 是 “有 哪些 老 乌 程序 员 知 道 而 新 手 不 知道 的 小 技巧 ”， 该 提问 下 有 一 个 很 意思 很 有 良心 的 回复 : 






































把 觉得 不 靠 谱 的 需求 放 到 最 后 做 。 很 可 能 到 时 候 需求 就 变 了 。 





一 一 知 乎 用 户 mu mu 














这 个 技巧 在 计算 机 科学 上 也 被 广泛 地 使 用 着 。 写 时 复制 采用 的 是 这 种 思想 ， 接 下 来 要 介绍 的 请 求 调 页 也 是 如 此 。 
在 操作 系统 领域 ， 未 雨 绸 缘 从 来 不 是 一 个 询 义 词 ， 因 为 这 往往 意味 着 会 做 大 量 的 无 用 功 。 



































请 求 调 页 是 一 种 动态 内 存 分 配 技术 ， 该 技术 把 页 面 的 分 配 推迟 到 不 能 再 推迟 为 止 。 也 就 是 说 ， 一 直 推 迟到 进程 要 
访问 的 地 址 不 在 物理 内 存 为 止 。 这 项 技术 的 核心 思想 是 ， 进 程 开始 运行 时 并 不 会 访问 其 地 址 空间 的 所 有 地 址 ， 事 实 
上 ， 有 些 地 址 进程 可 能 永远 都 不 会 访问 。 






























































一 旦 用 户 访问 映射 的 内 存 区 域 ， 就 会 触发 缺 页 中 断 。 以 arch/x86/mnyfault.c 中 的 do_page_fault 为 起 点 ， 其 调用 路 径 
如 图 11-21 所 示 。 














do page fault 


handle mm fault 





handle pte fault 




















图 11-21 缺 页 中 断 的 函数 调用 关系 





在 handle pte_ fault 中 有 如 下 代码 : 








entry = *pte; 
if (!pte present (entry)) { 
/*pte_none 表 示 没有 对 应 页 表 项 ， 内 核 需 要 从 头 开始 加 载 该 页 


4 
if (pte none(entry)) { 
/* 若 是 基于 文件 的 映射 ， 则 请 求 调 页 
二 
if (vma->vm ops) { 
if (likely (vma->vm |_ ops->fault)) 
return do linear fault (mm, vma, address, 
pte, pmd, flags, entry); 
} 
/* 若 是 匿名 映射 ， 则 按 需 分 配 
eh 
return do anonymous page (mm, vma, address, 
pte, pmd, flags); 
} 
/* 如 果 该 页 标记 不 存在 ， 但 是 页 表 中 保存 了 相关 的 信息 ， 则 表示 该 页 已 被 换 出 
活 


/ * 非 线性 映射 换 出 部 分 ， 不 能 像 普通 页 那样 换 入 ， 必 须 恢复 非 线性 关联 


Wi 


二 下 


(pte file(entry)) 
return do nonlinear fault (mm, 
pte, pmd, 


vma, 
flags, entry); 


address, 


return do swap page (mm, vma, address, 


pte, pmd, flags, 


entry); 








pte_present (entry〉 用 于 判断 页 硬 
































是 否 在 物理 内 存 中 。 如 果 页 面 并 不 在 物理 内 存 中 ， 那 么 处 理 流程 如 图 11-22 所 























图 11-22 ”页 下 












































于 判断 是 否 
根据 vma 的 vm ops 是否 注册 





pte_none 








会 调用 do _linear fault; 
页 


No 





如 果 pte_none 返 回 包 lse， 则 表示 页 表 中 保存 了 相关 的 信息 ， 这 郁 





存在 对 应 的 页 表 项 














do_swap_page 从 系统 的 某 个 交换 区 换 入 该 页 。 




















但 是 有 


函数 返 加 





























种 特殊 情况 ， 即 pte file 函数 返回 true 的 情况 。pte_file 函 数 用 于 检测 页 表 项 是 
true， 则 表示 页 表 项 属 

















不 在 物理 内 存 时 的 处 理 流程 


。 如 果 pte_none 为 tue， 那 么 内 核 必 须 从 头 开 始 加 载 该 
了 vm_ operation struct 而 分 成 两 类 : 如 果 vm_ops 不 是 NULL， 则 表示 是 基于 文件 
如 果 vm _ops 等 于 NULL， 则 表示 是 匿名 映射 ， 内 核 就 


FALSE 一 do_swap_ page 








。 这 种 情况 下 ， 
的 映射 ， 就 











会 调用 do_anonymous page 来 返回 一 个 匿名 
就 意味 着 该 页 已 经 被 换 出 ， 这 种 情况 下 应 该 调用 











否 属于 非 线性 映射 ， 如 果 该 





于 非 线性 映射 。 所 谓 非 线性 映射 是 指 在 mmap 的 基础 上 分 离 的 映射 页 。 尽 管 映 射 的 内 容 
仍然 是 文件 的 内 容 ， 但 是 与 映射 区 域 对 应 的 并 不 是 文件 的 连续 
随机 页 。 对 于 应 用 程序 而 言 ， 要 想 建立 非 线 性 映射 ， 首 先 需 要 调用 mmap 创 建 常规 的 、 








上 





区 间 ， 实 际 情 况 是 每 一 个 内 存 页 都 映射 的 是 文件 数据 的 
连续 的 内 存 映射 ， 然 后 调用 














remap_file_ pages 来 重新 映射 某 些 页 面 。 对 于 非 线性 映射 而 言 ， 已 经 换 出 的 部 分 不 能 像 普通 页 一 样 被 换 入 ， 首 先 必 须 正 








确 地 恢复 非 线性 关联 。 

















对 于 





向 的 就 是 flemap fault 函数 。 


filemap_ fault 函数 是 非常 习 


数 不 仅 可 以 读 入 所 需 的 数据 ， 还 


重要 





这 种 特殊 情况 ， 是 由 do_nonlinear fault 函 


享 文件 映射 ， 调 用 的 是 do_linear_ fault 函数。 在 该 函数 中 会 执行 vma->vm ops->fault 函 


属于 ext4 文 件 系 统 ， 那 么 mmap 系 统 调用 中 已 经 将 vma 的 vm_ ops 指定 成 了 ext4_file vm ops， 因 此 ，vma->vm ops->fault 指 











的 ， 不 仅仅 是 ext4 文 件 系 统 ， 
实现 了 预 读 的 功能 





数 负责 处 理 的 。 





数 。 如 果 对 应 的 文件 





还 有 很 多 文件 系统 都 使 用 flemap fault 来 处 理 缺 页 。 该 函 





。 接 下 来 ， 我 们 来 分 析 下 filemap_fault 函 数 。 





int filemap fault (struct vm area struct *vma, 


{ 
int error; 
struct file 


*file = vma->vm file; 


struct address space *mapping = file->f mapping; 


struct file ra state 


*ra = &file->f ra; 


struct inode *inode = mapping->host; 
pgoff t offset = vmf->pgoff; 


struct vm fault *vmf) 


struct page *page; 

pgoff t size; 

int ret = 0; 

size = (i size read(inode) + PAGE CACHE SIZE - 1) >> PAGE CACHE SHIFT; 

if (offset >= size) 加 本 
return VM FAULT SIGBUS; 

page = find get page (mapping, offset); 














当 多 个 进程 mmap 同 一 文件 的 某 个 区 域 时 ， 当 操作 映射 区 域 时 ， 更 多 的 情况 是 该 页 面 已 经 在 页 缓存 之 中 了 。 因 此 
filemap fault 首先 会 调用 file_get_ page 来 检查 请 求 页 面 是 否 已 经 在 页 缓存 之 中 了 。 



































如 果 页 缓存 中 确实 不 存在 请 求 的 页 面 ， 则 需要 调用 page_cache read 将 内 容 从 底层 块 设备 中 读 取 上 来 ， 其 函数 定义 
如 下 : 











static int page cache read(struct file *file, pgoff t offset) 
{ 

struct address_ space *mapping = file->f mapping; 

struct page *page; 


int ret; 

do { 
page = page cache alloc cold (mapping); 
if (!page) 


return -ENOMEM; 
ret = add to page cache lrul(page, mapping, offset, GFP KERNEL); 
if (ret == 0) 
ret = mapping->a ops->readpage (file, page); 
else if (ret == -EEXIST) 
ret = 0; /* losing race to add is OK */ 
page cache release (page); 
} while (ret == AOP _ TRUNCATED PAGE); 
return ret; 








mapping->a_ops 是 什么 ? 创建 ext4 inode 的 ext4_create 函 数 中 有 如 下 一 名 代码: 





ext4 set aops (inoqe) 














在 这 个 函数 中 我 们 通过 上 述 语句 设置 了 mapping 的 aops。 对 于 readpage 函 数 而 言 ， 最 终 是 通过 ext4 readpage 调 用 了 


通用 函数 mpage_ readpage。 如 图 11-23 所 示 。 


mapping->a ops->readpage 










































ext4 readpage 


mpage readpage 











图 11-23 ” 缺 页 中 断 当 page cache 中 不 存在 请 求 页 面 时 的 调用 路 径 











正 是 因为 页 缓存 的 存在 ， 才 真正 做 到 了 当 多 个 进程 mmap 同 一 个 文件 的 茶 个 区 域 时 ， 其 指向 的 物理 内 存 是 同一 个 
































事实 上 ， 系 统 文件 的 所 有 共享 都 是 基于 同一 条 路 线 的 ， 不 论 你 是 read、write 还 是 mmap， 都 要 遵循 这 条 路 线 : 系 
统 唯一 的 文件 路 径 到 系统 唯一 的 inode， 再 到 相同 的 address_space， 最 后 到 相同 的 页 面 。 





























我 们 跟踪 了 文件 映射 的 内 核实 现 ， 得 到 的 结论 是 页 缓存 是 联系 内 存 管理 系统 和 文件 系统 的 一 条 纽带 。 应 用 层 无 论 














是 使 用 read/write 系 统 调 用 还 是 mmap 将 文件 映射 到 内 存 ， 都 是 基于 页 缓存 的 ， 殊 途 同 归 。 因 此 通过 映射 获取 的 文件 视 
图 和 通过 VO 系统 调用 (read、write) 获得 文件 视图 是 一 致 的 。 





























理解 了 这 个 ， 我 们 就 可 以 讨论 如 下 这 类 的 话题 了 : 如 果 mmap 引 入 的 共享 文件 映射 ， 修 改 了 映射 区 的 内 存 后 ， 进 
程 却 意外 有 死亡， 那么 进程 对 内 存 的 修改 能 否 同步 到 底层 文件 ? 管 案 是 肯定 的 ， 页 高 速 缓存 到 底层 文件 的 冲刷 flush) 



































是 由 内 核 来 负责 的 。 事 实 上 ， 我 们 不 难 验证 这 一 点 。 对 这 个 话题 感 兴趣 的 话 ， 可 以 阅读 stackoverflow 上 的 相关 文章 出 












































关于 共享 文件 映射 ， 另 外 一 个 很 有 意思 的 现象 是 : 修改 映射 区 的 内 存 ， 哪 怕 是 几 个 字 节 ， 也 可 能 需要 花费 很 长 的 
时 间 《〈 比 如 几 百 毫秒 ) 中 。 很 多 人 都 遇 到 了 这 个 问题 B] ， 原 因 是 内 核 回 写 线程 会 负责 将 脏 页 回 写 ， 它 会 将 正在 回 写 
的 页 设置 成 写 保护 。 此 时 如 果 有 用 户 进程 对 该 页 面 执行 写 操作 ， 就 会 因为 碰 到 了 写 保护 的 页 面 而 走 到 do_page_fault。 
这 种 情况 下 ， 最 终 会 执行 到 handle pte_fault 中 的 如 下 语句 : 
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if (flags & FAULT FLAG WRITE) { 
if (!Ipte write (entry)) 
return do wp page (mm, vma, address, 
pte, pmd, ptl, entry); 
entry = pte mkdirty(entry); 

















在 do_ wp page 函数 中 会 调用 page_mkwrite 方 法 ， 在 这 里 会 等 待 回 写 线程 写 完 之 后 才 可 以 完成 对 页 面 的 写 操作 。 
考 文献 已 经 介绍 得 非常 详细 了 ， 限 于 篇 幅 此 处 就 不 展开 了 。 















































[1|] http://stackoverflow.conm/questions/5902629/mmap-msync-and-linux-process-termination。 
[2] 写 mmap 内 存 变 慢 的 原因 : http://oldblog.donghao.org/2012/02/mmapauaeaayaooo.html。 
[3] mmap internals: http://blog.chinaunix.net/uid-20662820-1d-3873318.html。 


11.4.4 私有 文件 映射 


当 调用 mmap 时 ， 如 果 将 flags 设 置 成 MAP _ PRIVATE 标志 位 ， 那 么 映射 就 是 私有 文件 映射 。 最 常见 
的 情况 就 是 前 面 提 到 的 加 载 动态 共享 库 ， 多 个 进程 共享 相同 的 文本 段 。 











从 下 面 执行 ls 时 执行 的 系统 调用 中 可 以 看 出 : 


open (' '/1ib/x86 64-1linux-gnu/libc.so.6", O RDONLY|O CLOEXEC) = 


read (3, I ‘7 832) = 832 
fstat(3, {st mode=S_ IFREG|0755, st size=1807032, ...}) = 0 
mmap (NULL, 3921080, ~ PROT READ|PROT EXEC, MAP PRIVATE|MAP DENYWRITE, 3, 0) = Ox7fe89alal000 





一 般 来 讲 文本 段 通常 被 保护 成 PROT READIPROT EXEC。 为 了 防止 恶意 程序 算 改 内 存 上 的 保护 信 
息 之 后 再 算 改 程序 或 共享 库 的 文本 ， 通 常会 直接 使 用 私有 文件 映射 而 不 是 共享 文件 映射 。 




















相对 于 出 现 得 更 早 的 静态 库 ， 动 态 库 有 很 多 的 优点 : 可 执行 文件 变 得 更 小 ， 节 省 磁盘 空间 ;内存 
中 只 需要 一 份 共享 库 的 实例 ， 不 同 进程 都 可 以 使 用 因而 节省 了 内 存 。 














11.4.5 ”共享 匿名 映射 











和 文件 映射 相对 应 的 是 匿名 映射 。 这 种 映射 并 没有 文件 与 之 对 应 。 一 般 来 讲 创 建 匿名 映射 有 两 种 
方法 : 





.调用 mmap 时 ， 在 参数 flags 中 指定 MAP_ANONYMOUS 标 志 位 ， 并 且 将 参数 但 指定 为 -1。 





.打开 /dewzero 设 备 文件 ， 并 将 得 到 的 文件 描述 符 包 传递 给 mmap。 


不 论 采用 哪 种 方式 ， 得 到 的 内 存 映 射 中 的 字 节 都 会 被 初始 化 成 0。 








本 节 介 绍 共享 匿名 映射 ， 下 一 节 将 介绍 私有 匿名 映射 。 调 用 mmap 创 建 匿 名 映射 时 ， 如 果 flags 设 置 
了 MAP_SHARED 标 志 位 ， 那 么 创建 出 来 就 是 共享 匿名 映射 。 共 享 匿 名 映射 的 作用 是 让 相关 进程 共享 
块 内 存 区 域 。 

















比如 父 进 程 创建 一 个 共享 匿名 映射 ， 然 后 fork 创 建 子 进程 ， 这 种 情况 下 ， 父 子 进程 就 可 以 通过 这 块 
内 存 区 域 来 通信 。 这 个 过 程 的 代码 如 下 所 示 。 





adqr = mmap (NULL, length, PROT READ|PROT WRITE, 
MAP SHARED|MAP ANONYMOUS, -1,0); 

if (addr == MAP FAILED) 

{ 


/*error handle*/ 


} 
child pid = fork() 


11.4.6 ”私有 匿名 映射 








当 创 建 匿名 映射 时 ， 如 果 flags 中 设置 了 MAP_PRIVATE 标 志 位 ， 那 么 创建 出 来 的 内 存 映射 就 是 私有 
匿名 映射 。 





这 种 映射 最 典型 的 用 途 是 分 配 进程 所 需 的 内 存 。 映 射出 来 的 内 存 并 没有 文件 与 之 关联 ， 对 内 存 的 
操作 也 是 私有 的 ， 不 会 影响 到 其 他 进程 。 该 用 途 比较 典型 的 例子 就 是 glibc 中 的 malloc 实 现 。 当 要 分 配 的 
内 存 大 于 MMAP_THREASHOLD 字 节 时 ，glibc 的 malloc 是 使 用 mmap 来 实现 的 。 一 般 来 讲 该 闪 值 是 
128KB， 可 以 通过 mallopt 函 数 来 调整 该 参数 。 











当代 码 中 有 如 下 内 容 时 : 





char *p = malloc(128*1024); 























通过 strace 来 跟踪 程序 的 执行 ， 我 们 可 以 清楚 地 看 到 程序 调用 了 mmap 系 统 调用 : 
mmap (NULL, 135168, PROT READ|PROT WRITE, MAP PRIVATE|MAP ANONYMOUS, -1, 0) = 0x7f2a29f0c000 


对 于 malloc 的 glibc 实 现 感 兴趣 的 话 ，Justin N.Ferguson 的 《Understanding the heap by break it》 是 一 篇 
非常 好 的 参考 文献 。 





11.5” ”POSIX 共享 内 存 








前 面 曾经 讲述 过 ，mmap 系 统 调用 做 了 大 量 的 工作 ，POSIX 共 享 内 存 和 前 面 的 共享 文件 映射 相 比 ， 
并 没有 什么 特殊 之 处 。 如 果 非 要 说 有 差别 ， 那 么 差别 就 是 ， 获 取 文 件 描述 符 的 方式 不 同 。 

















普通 文件 映射 获取 


工 Q 的 方式 


fd = open (filename,...); 


POSIX 共 享 内 存 获 取 


荆 Q 的 方式 


fd = shm open (name . . . ) ;使 用 


mmapP 映 射 到 进程 地 址 空间 


addr = mmap (NULL, length, PROT READ|PROT WRITE,MAP SHARED, fd,0); 





POSIX 共 享 内 存 可 以 在 无 关 的 进程 之 间 共 享 一 个 内 存 区 域 。 和 System V 信 号 相 比 ，POSIX 使 用 了 文 
件 系 统 来 标识 共享 内 存 ， 并 且 调 用 操作 文件 的 接口 来 操作 共享 内 存 。 每 创建 一 个 POSIX 共 享 内 存 ， 挂 载 
在 /dev/shm 下 的 tmpfs 文 件 系 统 中 就 会 新 增 一 个 文件 。 











和 System V 共 享 内 存 相 比 ，POSIX 共 享 内 存 的 大 小 可 以 动态 调整 ， 因 为 POSIX 共 享 内 存 是 基于 文件 
的 ， 所 以 可 以 很 方便 地 通过 ftruncate 函 数 来 调整 共享 内 存 的 大 小 。 共 享 内 存 的 使 用 者 可 以 通过 munmap 和 
mmap 重 建 映 射 。System V 共 享 内 存 的 大 小 在 创建 时 就 已 经 确定 ， 无 法 再 做 调整 。 








总 体 来 讲 ，POSIX 共 享 内 存 要 优 于 System V 共 享 内 存 ， 建 议 使 用 POSIX 共 享 内 存 。 


11.5.1 共享 内 存 的 创建 、 使 用 和 删除 





共享 内 存 的 创建 本 质 上 是 两 个 接口 ， 首 先是 调用 shm open 返回 文件 描述 符 ， 然 后 是 通过 mmap 将 共 
享 内 存 映 射 到 进程 的 地 址 空间 。 两 个 函数 的 搭配 很 像 SystemV 的 shmset 函 数 和 shmat 函 数 。 


shm_open 函 数 的 接口 定义 如 下 : 


#include <sys/mman.h> 

#include <sys/stat.h> 

#include <fcntl.h> 

int shm openl(const char xname int oflag, mode t mode); 





这 里 的 oflag 标 志 要 包含 O RDONLY 或 O RDWR 标 志 位 ， 除 此 以 外 ， 可 以 选择 的 标志 位 还 有 
O_CREAT (表示 创建 ) 、O_EXCL (配合 O_CREAT 表 示 排 他 创建 》 。 另 外 一 个 标志 位 是 O_TRUNC， 
表示 将 共享 内 存 的 Size 截断 成 0。 











mode 参 数 可 配合 O_CREAT 标 志 位 使 用 ， 用 于 设 定 共享 内 存 的 访问 权限 。 如 果 仅 仅 是 打开 共享 内 
存 ， 则 可 以 传递 0。shm open 总 是 需要 mode 参 数 。 





shm_ open 函 数 调用 成 功 时 ， 会 返回 一 个 文件 描述 符 。 内 核 会 自动 设置 FD_ CLOEXEC 标 志 位 ， 即 如 
果 进 程 执行 了 exec 函 数 ， 则 该 文件 描述 符 会 被 自动 关闭 。 














因为 共享 内 存 是 文件 ， 所 以 可 以 调用 文件 相关 的 函数 ， 如 人 stat 函 数 、fchmod 函 数 和 fcehwon 函 数 。 其 
中 最 重要 常用 的 函数 要 属 ftruncate 函 数 。 因 为 新 创建 的 共享 内 存 ， 默 认 大 小 总 是 0。 所 以 在 调用 mmap 之 
前 ， 需 要 先 调用 fruncate 函 数 ， 以 调整 文件 的 大 小 。 





(oy 























#include <unistd.h> 
irt ftruncate (int. fd, Off t length)y 


调整 了 size 之 后 ， 就 可 以 调用 mmap 函 数 将 共享 内 存 映 射 到 进程 的 地 址 空间 了 。 对 于 其 他 参与 通信 
的 进程 ， 可 能 需要 调用 fstat 接 口 来 获取 共享 内 存 区 的 大 小 。 








#include <sys/types.h> 

#include <sys/stat.h> 

#include <unistd.h> 

int fstat(int fd, struct :stat *buf); 


过 该 接口 可 以 获取 到 共享 内 存 的 大 小 。 


在 mmap 将 共享 内 存 映 射 到 进程 的 地 址 空间 之 后 ， 就 可 以 通过 操作 内 存 来 通信 了 。 对 这 块 内 存 的 所 
有 修改 ， 其 他 进程 都 可 以 看 到 。 











结束 通信 任务 后 ， 可 以 通过 调用 munmap 函 数 解 除 映 射 。 如 果 彻 底 不 需要 共享 内 存 了 ， 可 以 通过 


shm_unlink 函 数 来 删除 。 该 函数 的 接口 定义 如 下 : 





int shm unlink(const char *name); 








删除 一 个 共享 内 存 对 象 ， 并 不 会 影响 既 有 的 映射 。 内 核 维护 有 引用 计数 ， 当 所 有 的 进程 都 通过 
munmap 解 除 映 射 之 后 ， 共 享 内 存 对 象 才 会 真正 被 删除 。 

















如 果 不 执行 shm_unlink， 共 享 内 存 对 象 中 的 数据 则 具有 内 核 持久 性 。 哪 怕 所 有 的 进程 都 通过 munmap 
解除 了 映射 ， 只 要 不 调用 shm_unlink， 其 中 的 数据 就 不 会 丢失 。 妆 然 ， 如 果 系统 重启 ， 那 么 其 中 的 共享 
内 存 对 象 也 就 不 复 存 在 了 。 





11.5$.2 ”共享 内 存 与 tmpfs 


位 


POSIX 共 享 内 存 是 





立 在 tmpfs 基 础 之 上 的 。 事 实 上 ，System V 共 享 内 存 也 是 建立 在 tmpfs 基 础 上 的 。 


从 glibc 的 角度 来 看 ，shm open 的 实现 是 非常 简单 的 : 





#define SHMDIR (_PATH DEV "shm/") 
int 
shm open (const char *name, int oflag, mode t mode) 
{ 
size t namelen; 
char *fname; 
int Ed; 
/* 滤 除 用 户 给 出 的 名 字 中 的 一 个 或 多 个 





























/字符 
*#/ 
while (name[0] == '/') 
++name; 
if (name[0] == '\0') 
{ 
/* The name "/" is not supported. */ 
__ Set errno (EINVAL); 
return -1; 
} 
/* 这 一 部 分 是 生成 完整 的 路 径 名 
A 


namelen = strlen (name); 
fname = (char *) _alloca (sizeof SHMDIR - 1 + namelen + 1); 
__ mempcpy (_ mempcpy (fname, SHMDIR, sizeof SHMDIR - 1), 
name, namelen + 1); 
fd = open (name, oflag, mode); 
if (fd != -1) 
{ 
/* 给 文件 描述 符 设置 


FD_CLOEXEC 标 志 位 





*/ 
int flags = fcntl (fd, F GETFD, 0); 
if ( builtin expect (flags, 0) != -1) 
flags |= FD CLOEXEC; 
flags = fcntl1 (fd, F SETFD, flags); 





/* Something went wrong. We cannot return the descriptor. */ 
int save errno = errno; 
close (fd); 
fd = -1; 
_ Set errno (save errno); 
} 
} 


return fd; 





该 函数 就 做 了 三 件 事 : 


1) 生成 真正 的 文件 名 : 当 用 户 调用 shm open 传递 的 文件 名 为 name 时 ， 文 件 的 全 路 径 


是 /dev/shm/name。 





2) 创建 或 打开 /dewshnyname 文 件 。 
3) 给 打开 的 文件 设置 FD CLOEXEC 标 志 位 。 


前 文 兽 不 断 提 及 ，mmap 才 是 关键 ， 无 论 是 通过 open 获 取 到 人 锯 还 是 根据 shm_open 获 取 到 人 包 ， 并 没有 什 
么 本 质 的 区 别 。 看 到 glibc 的 shm_open 实 现 后 ， 我 们 更 能 够 理解 这 个 观点 ， 的 确 没 有 本 质 区 
别 ，shm open， 不 过 就 是 open 披 了 一 个 马夹 。 


接 下 来 可 以 讲 讲 tmpfs 相 关 的 内 容 了 。 在 shm_open 的 实现 中 选择 /dev/shm 这 个 路 径 并 不 是 随意 而 为 之 
的 。glibc 为 了 实现 POSIX 共 享 内 存 ， 需 要 将 一 个 tmpfs 挂 载 到 /dev/shm 这 个 路 径 下 。 











tmpfs 是 一 个 内 存 文件 系 统 ， 该 文件 系统 可 将 所 有 的 文件 内 容 保 持 在 内 存 之 中 ， 而 不 会 写 入 到 磁盘 
等 持久 化 的 设备 中 。 一 旦 umount 或 系统 重启 ，tmpfs 里 的 内 容 就 会 全 部 丢失 。 


内 核 的 文档 中 Documentation/filesystems/tmpfs.txt 中 介绍 了 tmpfs 的 作用 : 














:总 是 存在 内 核 的 内 部 挂 载 (internal mount) ， 这 个 内 部 挂 载 并 不 依赖 于 CONFIG_TMPFS， 哪 怕 
CONFIG_TMPFS 编 译 选 项 没有 打开 ， 也 不 会 影响 到 该 内 部 机 制 的 存在 。 它 的 存在 是 为 共享 匿名 映射 和 


System V 共 享 内 存 服务 的 。 























“glibc 自 2.2 版 本 以 来 ， 为 了 实现 POSIX 共 享 内 存 的 功能 ， 需 要 一 个 挂 载 点 为 /dev/shm 的 tmpfs。 

















从 文档 中 可 以 看 出 ， 无 论 是 POSIX 信 号 量 、System V 信 号 量 还 是 共享 匿名 映射 都 是 建立 在 tmpfs 的 基 
础 上 的 ， 其 统一 的 视图 如 图 11-24 所 示 。 




















System V : POSIX 
Shared memory 共享 匿名 映射 Shared memory 











对 于 System V 共 享 内 存 而 言 ， 其 核心 是 tmpf， 外 面 封装 了 一 层 用 来 管理 IPC 的 键 值 。 当 调用 shmget 
创建 System V 共 享 内 存 时 ， 会 调用 ipc/shm.c 中 的 newseg 函 数 。 该 函数 会 调用 位 于 mnmyshmem.c 文 件 中 的 
shmem file_setup 函 数 来 创建 一 个 与 共享 内 存 对 应 的 struct file。 代 码 如 下 所 示 : 

















sprintf (name, "SYSV%08x", key); 
if (shmflg & SHM HUGETLB) { 
/* hugetlb file setup applies strict accounting */ 
if (shmflg & SHM NORESERVE) 
accti lag = = VM NORESERVE; 
filé = hugetlb. file setup (name, size, acctflag, 
&shp— >mlock user, HUGETILB SHMFS INODE); 























} else 1{ 
if ((shmflg & SHM NORESERVE) && 
Sysctl overcommit memory != OVERCOMMIT NEVER) 
acctflag = VM NORESERVE; 
file = shmem file setup(name, size, acctflag); 





























} 





当 调 用 shmat 函 数 将 System V 共 享 内 存 attach 到 进程 的 地 址 空间 时 ， 内 核 会 通过 do_mmap 函 数 ， 创 建 
出 基于 该 文件 的 共享 映射 ， 提 供给 用 户 使 用 。 毫 不 意外 ， 当 用 户 调用 shmdt 函 数 解除 映射 时 ， 内 核 会 调 


用 do_munmap 。 





在 Linux 实 现 中 ， 传 统 的 System V 共 享 内 存 虽 然 没 有 显 式 地 调用 open-mmap-munmap 这 套 流 程 ， 但 是 
内 在 的 核心 逻辑 是 一 致 的 。shmset 获 得 了 一 个 tmp 氏 的 文件 实例 ，shmat 函 数 内 部 对 应 mmap， 而 shmdt 函 数 
内 部 对 应 munmap 。 





接 下 来 分 析 共 享 匿 名 映射 。 创 建 共享 匿名 映射 有 两 条 路 ， 其 中 一 条 就 是 打开 /dev/zero 文 件 ， 将 获得 
的 文件 描述 符 和 传递 给 mmap 函 数 。/dev/zero 是 一 个 特殊 的 文件 ， 在 drivers/char/mem.c 中 有 如 下 内 容 : 





static const struct memdev { 
const char *name; 
mode 七 mode; 
const struct file operations *fops; 
struct backing dev info *dev info; 
} devlist[] = { 


[5] = { "zero" 0666, &zero fops, &zero bdi }, 


static const struct file operations zero fops = { 
.llseek = Zero lseek, 


.read = read zero, 
.write = write zero, 
.mmap = mmap_ zero, 


如 果 打 开 /dew/zero 文 件 ， 并 将 获得 的 文件 描述 符 人 乌 传 给 mmap 系 统 调 用 ， 那 么 内 核 中 mmap J 
数 中 调用 的 fle->f op->mmap 函 数 ， 实 质 上 调用 的 是 mmap _ zero 函数 ， 而 mmap_ zero 函数 ， 不 过 
shmem zero_setup 函 数 的 简单 封装 。 


static int mmap zero(struct file *file, struct vm area struct *vma) 


{ 
#ifndef CONFIG MMU 
return -ENOSYS; 
#endif 
if (vma->vm flags & VM SHARED) 
return shmem Zero _setup (vma); 
return 0; 


创建 共享 匿名 映射 的 另外 一 条 路 是 调用 mmap， 传 递 -1 作为 包 的 值 。 这 种 情况 下 也 会 走 到 
shmem zero_setup 函 数 。 请 看 mmap region 函 数 中 的 如 下 代码 : 








主 主人 上) 叫 


}else :if (vm flags & VM SHARED) { /* 共 享 匿名 映射 处 理 迎 辑 


A 
error = shmem zero setup (vma); 
if (error) 
goto free vma; 


} 


殊途同归 ， 无 论 采 用 哪 种 方式 创建 共享 匿名 映射 ， 最 终 都 会 调用 到 shmem zero_setup 函 数 。 而 该 函 
数 仅 仅 是 shmem file setup 的 简单 封装 。 





POSIX 共 享 内 存 前 面 已 经 分 析 过 了 ， 通 过 挂 载 到 /devshm 路 径 下 的 tmpf 来 实现 内 存 的 共享 。8glibc 的 
shm_open 用 于 创建 一 个 文件 ， 并 且 通 过 mmap 映 射 到 进程 的 地 址 空间 。 











从 上 面 的 讨论 也 可 以 看 出 ，mmap 和 tmpfs 是 隐藏 在 共享 内 存 背 后 的 终极 boss。 无 论 是 System V 共 享 
内 存 ， 还 是 POSIX 共 享 内 存 ， 都 摆脱 不 了 tmp 氏 和 mmap。 区 别 仅仅 是 POSIX 共 享 内 存 很 直接 ， 就 是 直接 























在 tmpfs 下 创建 文件 ， 直 接 通 过 mmap 来 使 用 内 存 区 域 ， 而 System V 共 享 内 存 穿 了 马甲 ， 将 tmp 人 fs 和 mmap 的 
相关 操作 隐藏 到 了 内 核 中 。 

















对 tmpf8 和 共享 内 存 感 兴趣 的 话 ，《 浅 析 Linux 共 享 内 存 和 tmpfs》 上 是 一 篇 不 错 的 参考 文档 。 


[1] http://hustcat.github.io/shared-memory-tmpfs/。 


第 12 章 ”网 络 通 信 : 连接 的 建立 





在 互联 网 时 代 ， 网 络 通信 编程 已 经 是 一 个 程序 员 必 不 可 少 的 技能 之 一 。 几 乎 所 有 的 产品 都 会 涉及 
网 络 操作 或 访问 。 在 Linux 编 程 环境 中 ， 系 统 提 供 了 socket 套 接 字 为 程序 员 提供 统一 的 网 络 编程 接口 。 








本 书 将 对 socket 套 接 字 进行 详细 的 分 析 ， 由 于 篇 幅 较 多 ， 所 以 将 内 容 分 为 三 章 来 讲述 。 本 章 主要 讲 
解 与 连接 相关 的 分 析 ， 包 括 socket、bind、connect、listen 和 accept 系 统 调用 及 相关 的 源码 追踪 。 这 里 假 
设 读者 有 一 定 的 Linux 网 络 编程 基础 ， 所 以 对 于 系统 调用 的 解释 都 是 点 到 为 止 ， 只 针对 不 常见 或 容易 忽 
视 的 问题 进行 详细 说 明 。 














12.1 socket 文 件 描述 符 























socket 翻 译 成 中 文 是 插座 、 插 槽 的 意思 ， 而 在 网 络 编程 中 ， 其 被 翻译 为 “ 套 接 字 ”。Linux 环 境 下 ， 我 们 经 常 说 “一 切 皆 文件 "。 因 此 套 接 字 也 被 
视 为 一 种 文件 描述 符 。 首 先 ， 来 看 看 如 何 使 用 socket 系 统 调 用 创建 一 个 套 接 字 ， 代 码 如 下 : 





















































#include <sys/types.h> /* See NOTES */ 
#include <sys/socket.h> 
int socket (int domain, int type, int protocol); 








其 中 的 参数 解释 如 下 。 








-domain: 用 于 指示 协议 族 名 字 ， 如 AF_INET 为 IPv4。 


























-type: 用 于 指示 类 型 ， 如 基于 流通 信 的 SOCK_STREAM。 














“protocol: 用 于 指示 对 于 这 种 socket 的 具体 协议 类 型 。 一 般 情况 下 ， 使 用 前 两 个 参数 限定 后 ， 只 会 存在 一 种 协议 类 型 对 应 该 情况 。 这 时 ， 可 
以 将 protocol 设 置 为 0。 但 是 在 某 些 情况 下 ， 会 存在 多 个 协议 类 型 ， 这 时 就 必须 指定 具体 的 协议 类 型 。 









































成 功 创建 socket 后 ， 会 返 


I 


个 文件 描述 符 。 失 败 时 ， 该 接口 返回 -1。 



































那么 对 于 Linux 内 核 来 说 ， 如 何 知道 一 个 文件 描述 符 是 一 个 套 接 字 ， 还 是 一 个 普通 文件 呢 ? 其 实 这 个 问题 也 可 以 扩展 到 ， 内 核 如 何 知道 一 个 
文件 描述 符 的 具体 类 型 ， 如 何 调用 实际 类 型 的 操作 函数 呢 ? 这 仍然 是 VFS 的 魔力 。 





















































在 第 1 章 中 ， 我 们 了 解 了 文件 描述 符 弓 与 内 核 文件 结构 struct file 之 间 的 关系 ， 后 者 是 内 核 用 于 管理 文件 的 真正 结构 ， 其 中 的 成 员 变 量 file- 
>f op 为 VFS 支 持 的 所 有 文件 操作 。VFS 层 无 须 关 心 该 文件 file 的 实际 类 型 ， 它 会 直接 调用 file->f op 中 的 操作 函数 《这 样 的 处 理 ， 与 面向 对 象 语言 
中 的 多 态 是 类 似 的 ) 。 







































































UD 








对 于 套 接 字 来 说 ， 只 要 在 创建 套 接 字 时 ， 将 file->f op 设置 为 正确 的 套 接 字 操 作 函 数 即 可 。 该 操作 是 在 socket>sock map fd->sock alloc_file 
完成 的 ， 代 码 如 下 : 




















static int sock alloc file(struct socket *sock, struct file **f, int flags){ 


$n 申请 一 个 


struct file, 并 将 


Socket _file_ops 作 为 参数 来 传递 。 


在 


alloc_ file 中 , 会 将 


Socket_file_ops 研 给 


file 


*/ file = alloc file(g&path, FMODE READ | FMODE WRITE, &socket file ops); 


jw 刘 


SOCK->file 指 向 


file, 完成 



















































































SOCK 和 
fi1e 的 关联 
*/ sock->file = file; file->f flags = O_RDWR (flags & O NONBLOCK); file->f pos = 07 file->private data = sock; *£ = filey return fd;} 
尽管 Linux 内 核 是 使 用 C 语 言 编写 的 ， 但 是 其 应 用 了 很 多 面向 对 象 的 设计 思想 。 以 这 里 的 包 e 为 例 ， 内 核 利 月 

指向 具体 对 象 的 操作 函数 集合 。 这 样 一 来 ， 对 于 VEFS 来 说 ， 前 

的 处 理 函 数 。 








it 只 须 关 心 struct file， 而 无 须 关 心 























有 op 〈 对 象 操作 函数 指针 集合 ) 
\ 体 的 对 象 类 型 了 ， 它 会 在 处 理 过 程 中 


时 中 ， 调 用 正确 











12.2 ” 绑 定 下 地 址 





在 成 功 创建 套 接 字 后 ， 该 套 接 字 仅仅 是 一 个 文件 描述 符 ， 并 没有 任何 地 址 与 之 关联 。 使 用 该 socket 
发 送 数据 包 时 ， 由 于 该 socket 没 有 任何 耳 地 址 ， 内 核 会 根据 策略 自动 选择 一 个 地 址 。 但 是 ， 在 某 些 情况 
下 ， 我 们 需要 手工 指定 socket 使 用 哪个 PP 地 址 进行 发 送 。 这 时 ， 就 需要 使 用 bind 系 统 调用 了 。 




















12.2.1 bind 的 使 用 





























bind 系 统 调用 的 接口 定义 如 下 : 





#include <sys/types.h> /* See NOTES */ 


#include <sys/socket.h> 
int bindl(int sockfd, const struct sockaddr *addr, socklen t addrlen); 





其 中 的 参数 解释 如 下 。 
“sockfd: 表示 要 绑 定 地 址 的 套 接 字 描述 符 。 
“addr: 表示 绑 定 到 套 接 字 的 地 址 。 


“addrlen: 表示 绑 定 的 地 址 长 度 。 





五 


返回 值 0 表 示 成 功 ，-1 则 表示 错误 。 





















































1 ， 统 一 使 用 了 一 个 公共 结构 体 ， 并 要 求 








为 为 Linux 的 套 接 字 是 针对 多 种 协议 族 的 ， 而 每 个 协议 族 都 可 以 有 不 同 的 地 址 类 型 。 所 以 Linux 套 接 字 关于 地 址 的 系统 调 
调用 者 将 实际 地 址 参数 进行 强制 类 型 转换 ， 以 此 来 避免 编译 警告 。 












































struct sockaddr { sa family t sa family; char sa data[14];} 








天 为 每 个 协议 族 的 地 址 类 型 各 不 相同 ， 所 以 需要 通过 参数 addrlen 来 告诉 内 核 这 个 地 址 的 实际 大 小 。 












































为 套 接 字 接口 要 支持 所 有 的 协议 族 ， 所 以 涉及 地 址 的 地 方 都 使 用 了 一 个 统 








By 




















四 
说 明 ”struct sockaddr 数 据 类 型 会 在 socket 涉 及 地 址 的 所 有 接口 中 出 现 。 这 是 
的 地 址 结构 struct sockaddr。 


下 面 是 一 个 简单 示例 : 








#include <stdlib.h>#include <stdio.h>#include <unistd.h>#include <sys/types.h>#include <sys/socket.h>#include <arpa/inet.h>#define LOOPBACK ADDR 0x7F000001#define LISTEN PORT 




















环 地 址 127.0.0.1 和 端口 1234 绑 定 到 这 个 套 接 字 上 。 运 行 这 个 程序 ， 然 后 通过 netstat 检 查 监 听 端 











| 











在 上 面 的 示例 中 ， 我 们 创建 了 一 个 TCP 套 接 字 ， 并 将 








[fgao@ubuntu ~]#netstat -ant 

Active Internet connections (servers and established) 
Proto Recv-Q Send-Q Local Address Foreign Address State 

tcp 0 0 27,.0.0.1:1234 0.0.0.03* LISTEN 




















从 上 面 的 输出 可 以 看 到 ， 创 建 的 套 接 字 已 经 成 功 地 绑 定 了 指定 的 地 址 和 端 








12.2.2 ”bind 的 源码 分 析 


bind 源 码 入 口 位 于 net/socket.c 中 ， 如 下 所 示 : 











SYSCALL _ DEFINE3 (bind, int, fd, struct sockaddr _user *, umyaddr, int, addrlen){ 


前 文 已 经 介绍 了 


struct socket. 


下 ad 与 


Struct socket 的 关联 关 





bh sock = sockfd lookup light (fd, &err, &fput needed); if (sock) { 


struct socket *sock; 


struct sockaddr storage address; int err, fput needed;/* 


/* umyaddr 是 用 户 空间 地 址 ， 这 里 将 其 复制 到 内 核 空间 


由 文件 描 





















































address 变 遇 中 

*/ err = move addr to kernel (umyaddr, addrlen, (struct sockaddr *)&address); if (err >= 0) { /* 对 

ind 动 作 进 行 安全 性 从 查 

*/ err = security socket bind(sock, (struct sockaddr *) &address, addrlen) ; if (lerr) { /* 调用 对 应 协议 的 

bina 动 作 

*/ err = sock->ops->bind(sock, (struct sockaddr *) gaddress, addrlen); } i fput_light (sock- 
在 bind 的 调用 中 ， 根 据 不 同 的 协议 调用 不 同 的 实现 函数 〈Linux 的 内 核 代 码 中 ， 大 量 使 用 了 这 种 面向 对 象 的 设计 思路 ) 。 对 于 AF_INET 协 议 族 来 说 ， 无 论 是 面向 




















TT 











接 的 SOCK_STREAM 类 型 ， 还 是 SOCK_DGRAM 协 议 类 型 ， 








实现 函数 均 是 inet_bind。 下 





























来 看 











下 inet_bind 的 具体 实现 : 























int inet bind(struct socket *sock, struct sockaddr *uaddr, int addr len){ 
如 果 有 具体 协议 实现 了 


bing 函 数 ， 则 调用 协议 的 


了 ind 函数 。 


RE INET 协 议 族 中 ， 只 有 


IPPROTO ICMP 和 


IPPROTO _IP 实 现 了 自己 的 


bing 函 数 ， 


IPPROTO TCP 和 


IPPROTO_UDP 都 使 用 


AF_INET 通 用 的 函数 ， 即 


inet bind. 


*/ if (sk->sk prot->bind) { err = Sk->sk prot->bind(sk, uaddr, addr len); 


二 大 if (addr len < sizeof (Struct sockaddr in) ) goto out; 





struct sockaddr in *addr = 


goto out;} 


if (addr->sin family != AF INET) { 


(struct sockaddr in *)uaddr; 


struct sock *sk = sock->sk; 


err = -EINVAL; /* 检查 地 址 长 度 


/* 本 来 要 求 地 址 的 协议 族 要 与 


struct in 


AF_INET,， 但 是 这 里 有 个 兼容 性 问题 。 允 许 协 


议 族 为 


AF_UNSPEC 并 且 地 址 为 


INADDR_ANY 的 任意 地 址 


A err = -EAFNOSUPPORT; 


if (addr->sin family != AF UNSPEC || 


addr->sin addr.s addr != hton]l (INADDR ANY)) 


*/ chk addr ret = inet addr type(sock net (sk), addr->sin addr.s addr); err = -EADDRNOTAVAIL; /* 


SYSct1_ ip_nonlocal bind 系 统 控 制 开关 ， 允许 


bing 非 本 地 


IP; inet->freebind 为 一 个 


SOCKket 选 项 ， 允 许 该 


socket bind 任 意 


IP; 在 上 面 这 些 变量 均 不 成 立时 ， 指 定 地 址 又 不 





本 地 地 址 


INADDR_ANY， 地址 类 型 又 不 是 本 地 地 址 类 型 ， 多 播 或 广播 时 ， 则 


了 ind 失 败 。 


烛光 if (!sysctl ip nonlocal bind && 


PROT SOCK (1024)， 则 需要 检查 用 户 是 否 有 权限 创建 知名 端口 


*/ if (snum && snum < PROT SOCK && !capable (CAP NET BIND SERVICE)) 


bing 两 





*/ if (sk->sk state != TCP CLOSE || inet->inet num) 


be inet->inet rcv saddr = inet->inet saddr 


0， 表 示 在 发 送 时 ， 使 用 的 是 设备 地 址 


#7 if (chk addr ret == RIN MULTICAST || chk addr ret == RTN BROADCAST) 


get_port， 判 断 该 端口 是 否 可 以 使 用 。 


虽然 这 里 是 一 个 查询 的 动作 ， 但 是 却 会 有 修改 的 动作 。 


当 该 端口 可 以 使 用 时 ， 会 让 


inet sk(sk)->inet num = snum; 


inet_nurm， 这 样 既 可 以 保证 设置 端口 的 原子 性 ， 同 时 还 可 以 提高 性 能 


*/ if (sk->sk prot->get port(sk, snum)) 


! (inet->freebind 


addr->sin addr.s addr; 


inet->inet saddr = inet->inet rcv saddr 


inet->transparent) 


goto out; 


goto out release sock; 


这 样 做 ， 是 因为 查询 动作 已 经 获得 了 锁 。 在 确定 可 以 使 用 该 端口 时 ， 直 接 修 


&& 


lock sock (sk); 


addr->sin addr.s addr != htonl (INADDR ANY) 


err = -EINVAL; 


/* 使 用 参数 设置 套 接 字 的 接收 和 发 送 地 址 


inet->inet saddr = 0; 


/* 如 果 参 数 地 址 是 多 播 或 广播 类 型 ， 则 重 兽 发 送 源 地 址 为 


/* Use device */ 


07 err = -EADDRINUSE; 


/* 确保 套 接 字 不 会 被 


&& 


调用 协议 自 定义 的 操作 函数 


goto out release sock; } 


goto out; } 


/* 判断 地 址 类 型 


chk addr ret != RTN LOCAL && 


/* 如 果 设 置 了 


ind 地 址 ， 则 置 上 相应 的 标志 


i# if (inet->inet rcv_ saddr) Sk->sk userlocks |= SOCK BINDADDR LOCK; /* 如 果 设 置 了 源 端口 ， 则 设置 相应 的 标志 


*/ if (snum) sk->sk_userlocks |= SOCK BINDPORT LOCK; /* 设置 


inet sport， 其 为 网 络 序 


gf inet->inet sport = htons (inet->inet num); /* 重 置 目的 地 址 和 端口 
A inet->inet daddr = 0} inet->inet dport = 0; /* 重 置 访 套 接 字 的 路 由 信息 
*/ Sk dst reset (sk); err = 0; out release sock: release sock(sk); out: return err; } 












































无 论 是 APUE 还 是 man 手 册 ， 在 讲解 bind 的 时 候 都 有 点 问题 ， 或 有 偏差 ， 或 不 够 详尽 。 从 上 面 的 源码 我 们 知道 ， 通 过 使 用 系统 控制 开关 sysctl_ip_nonlocal bind 或 套 
接 字 选 项 可 以 让 套 接 字 bind 一 个 非 本 机 地 址 。 但 APUE 却 说 套 接 字 只 能 绑 定 本 机 的 有 效 地 址 一 当然 这 也 是 由 于 APUE 距 现在 的 时 间 太 久 了 ， 而 man 手 册 都 没有 提 及 非 
本 机 地 址 的 民 
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Hl 
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12.3 客户 端 连 接 过 程 
12.3.1 ”connect 的 使 用 


connect 的 原型 为 : 


#include <sys/types.h> /* See NOTES */ 
#include <sys/socket.h> 
int connect (int sockfd, const struct sockaddr *addr, socklen t addrlen); 


其 中 的 参数 解释 如 下 : 





“int sockfd: 套 接 字 描述 符 。 

















-const struct sockaddr*addr: 要 连接 的 地 址 。 





.Socklen taddrlen: 要 连接 的 地 址 长 度 。 
返回 值 0 表 示 成 功 ，-1 表 示 失 败 。 


connect 的 用 途 是 使 用 指定 的 套 接 字 去 连接 指定 的 地 址 。 对 于 面向 连接 的 协议 〈 套 接 字 类 型 为 
SOCK_STREAM) ，connect 只 能 成 功 一 次 《当然 要 如 此 ， 因 为 真正 的 连接 已 经 建立 了 ) 。 如 果 重 复 调 
用 connect， 会 返回 -1 表示 失败 ， 同 时 错误 码 为 EISCONN。 而 对 于 非 面向 连接 的 协议 〈 套 接 字 类 型 为 
SOCK_DGRAM) ， 则 可 以 执行 多 次 connect〈 因 为 这 时 的 connect 仅 仅 是 设置 了 默认 的 目的 地 址 ) 。 














对 于 TCP 套 接 字 来 说 ，connect 实 际 上 是 要 真正 地 进行 三 次 握手 ， 所 以 其 默认 是 一 个 阻塞 操作 。 那 么 
是 否 可 以 写 一 个 非 阻塞 的 TCP connect 代 码 呢 ? 这 是 一 个 合格 的 网 络 开发 工程 师 的 基本 功 ， 有 具体 的 实现 
可 以 参看 UNPv1 的 实现 。 更 重要 是 要 理解 其 原理 ， 这 样 才能 在 需要 的 时 候 ， 信 手 牛 来 。 
































12.3.2 ”connect 的 源码 分 析 











connect 的 源码 入 口 位 于 socket.c， 代 码 如 下 : 














SYSCALL DEFINE3(connect, int, fd, struct sockaddr user *, uservaddr, int, addrlen){ struct socket *sock; struct sockaddr storage address; int err, fput needed; 





struct socket */ sock = sockfd lookup light (fd, &err, &fput needed); if (!sock) goto out; /* 将 用 户 空间 地 址 复制 到 内 核 空间 变 


address 中 
*/ err = move addr to kernel (uservaddr, addrlen, (struct sockaddr *)&address); if (err < 0) goto out put; /* 安全 性 检查 
*/ err = security socket connect (sock, (struct sockaddr *)é&address, addrlen); if (err) goto out put; /fs 与 


ind 类 似 ， 调 用 与 协议 族 对 应 的 


Connect 操 作 函 数 


于 这 err = sock->ops->connect (sock, (struct sockaddr *)&address，addrleny sock->file->f flags);out put: fput light (sock->file, fput needed);out: 


return err 















































对 于 AF_INET 协 议 族 来 说 ， 
为 inet_dgram connect。 这 很 合理 ， 因 为 从 connect 的 功能 实现 上 看 ， 两 者 的 实现 效果 完全 不 同 。 


























让 我 们 先 从 简单 的 inet_dgram connect 入 手 。 





连接 的 协议 类 型 是 SOCK_STREAM， 其 连接 函数 为 inet_stream connect， 而 非 面向 连接 的 协议 类 型 SOCK DGRAM， 其 连接 函数 





int inet dgram connect (struct socket *sock, struct sockaddr * uaddr, int addr len, int flags){ struct sock *sk = sock->sk; /* 长 度 合法 性 检查 


eA if (addr len < sizeof (uaddr->sa family)) return -EINVAL; /* 如 果 协 议 族 为 


RE UNSPEC， 则 先 执行 





disconnect */ if (uaddr->sa family == AF UNSPEC) return sk->sk prot->disconnect (sk, flags); /* 如 果 该 套 接 字 没有 指 口 ， 并 且 系 统 自动 绑 定 端口 失败 ， 则 返回 错误 
*/ if (!inet sk(sk)->inet num && inet autobind (sk)) return -EAGAIN; /* 调用 具体 协议 的 

Connect 实 现 函 数 

A return sk->sk prot->connect (sk, (struct sockaddr *)uaddr, addr len);} 

















udp_prot 是 UDP 协 议 中 所 有 自 定义 操作 函数 的 集合 。 其 connect 的 实现 函数 为 ip4_datagram connect。 





int ip4 datagram connect (struct sock *sk, struct sockaddr *uaddr, int addr len){ struct inet sock *inet = inet sk(sk); struct sockaddr in *usin = (struct sockaddr in *) u 


*/ if (addr len < sizeof (*usin)) return -EINVAL; /* 检查 是 否 为 


AF_INET 协 议 族 


a if (usin->sin family != AF_INET) return -EAFNOSUPPORT; A.e 因为 


Connect 会 改变 目的 地 址 ， 所 有 


SOCKket 中 保存 的 路 由 缓存 已 经 无 用 ， 必 须 重 置 。 


wf Sk dst reset (sk); lock sock (sk); /* 得 到 套 接 字 绑 定 的 发 送 接口 


二 oif = sk->sk bound dev if; saddr = inet->inet saddr; /* 在 目的 地 址 是 多 播 地 址 的 情况 下 ， 





没有 绑 定 网 卡 ， 则 出 口 网 卡 为 设置 的 多 播 网 卡 索 引 ; 





接 字 没 有 绑 定 源 


IP， 则 使 用 设置 的 多 播 源 地 址 ; 


直 关 if (ipv4 is multicast (usin->sin addr.s adqdr)) { 1 od oif = inet->mc index; if (!saddr) saddr = inet->mc addr; } /* 判断 设置 的 
* £14 = &inet->cork.fl.u.ip4; rt = ip route connect (f14, usin->sin addr.s addr, saddr, RT CONN FLAGS (sk), oif, Sk->sk_ protocol, 
id if ((rt->rt flags & RTCF BROADCAST) && !sock flag(sk, SOCK BROADCAST)) { ip rt put(rt); err = -EACCES; goto out; } /* 如 果 套 接 字 没 有 设置 发 送 地 址 或 接收 地 址 ， 则 使 用 
*/ if (!inet->inet saddr) inet->inet saddr = f14->saddr; /* Update source address */ if (linet->inet rcv saddr) { inet->inet rcv saddr = f14->saddr; if 
思考 inet->inet daddr = f14->daddr; inet->inet dport = usin->sin port; Sk->sk_state = TCP ESTABLISHED; inet->inet id = jiftiesy /* 重新 设置 路 由 人 





机 下 Sk dst set(sk, &rt->dst); err = 0;out: release sock (sk); return err;} 


































































































由 于 功能 比较 简单 ， 所 以 UDP 的 connect 实 现 源码 也 了 然 ， 可 以 看 到 ， 只 是 设置 了 目的 全 、 端 口 和 路 由 信息 。 下 面 对 比 一 下 TCP 的 connect 实 现 ， 其 实现 比 UDP 
要 复杂 得 多 ， 代 码 如 下 : 
int inet stream connect (struct socket *sock, struct sockaddr *uaddr, int addr len, int flags){ 从 
SOCKket 结 构 获 得 
SOCK 结 构 ， 后 者 是 内 核 真正 用 于 管理 网 络 层 的 套 接 
字 结 构 
和 struct sock *sk = sock->sk; int err; long timeo; /* 地 址 长 度 检查 
*/ if (addr len < sizeof (uaddr->sa family)) return -EINVAL; lock sock (sk) 7 /* 对 
RE UNSPEC 兼 容 性 处 理 
坝 开 if (uaddr->sa family == AF UNSPEC) { err = sk->sk prot->disconnect (sk, flags); sock->state = err ? SS DISCONNECTING : SS UNCONNECTED; goto out; } 
STREAM 协 议 是 有 连接 状态 的 ， 所 以 需要 对 套 接 字 进行 状态 检查 
wy switch (sock->state) { default: err = -EINVAL; goto out; /* 若 连 接 已 经 建立 ， 则 返回 错误 
过 case SS_CONNECTED: err = -EISCONN; goto out; /* 车 连接 正在 进行 中 ， 则 返回 错误 
A case SS _ CONNECTING: err = -EALREADY; /* Fall out of switch with err, set for this state */ break; /* 当前 为 未 连接 状态 
二 case SS_UNCONNECTED: err = -EISCONN; /* sock 的 状态 是 未 连接 ， 但 是 套 接 字 的 
Sk_state 却 不 是 关闭 状态 ， 
此 时 无 法 进行 连接 
wy if (sk->sk state != TCP CLOSE) goto out; 种 既然 需要 产生 连接 ， 那 么 每 种 具体 的 协议 肯定 都 有 自己 的 实现 
所 以 这 会 调用 具体 协议 的 实现 函数 。 
并 err = sk->sk prot->connect (sk, uaddr, addr len); if (err < 0) goto out; /* 将 
SOCk 状 态 更 改 为 正在 连接 中 
本 Sock->state = SS_ CONNECTING; /* Just entered SS_CONNECTING state; the only * difference is that return value in non-blocking * case is EINPROGRE 


卫 INPROGRESS， 表 示 正 在 连接 中 。 


Connect 为 非 阻塞 时 ， 就 会 返回 这 个 错误 









































训 光 err = -EINPROGRESS; break; } Eh 检查 是 否 需 要 连接 超时 。 若 设置 了 非 阻塞 标志 ， 则 
七 imeo 为 假 。 
若 设置 了 阻塞 标志 ， 则 
timeo 为 真 。 
次 交 timeo = sock sndtimeo(sk, flags & O NONBLOCK); /* 当前 连接 状态 为 正在 连接 的 状态 即 刚 发 送 了 
Syn 或 收 到 
Syn) 
wy if ((1 << sk->sk state) & (TCPF SYN SENT | TCPF SYN RECV)){ /* 如 果 没 有 超时 标志 或 连接 超时 或 失败 ， 则 返回 
A if (!timeo || !inet wait for connect (sk, timeo)) goto out; /* 判断 是 否 由 于 信号 导致 等 待 连接 退出 
eA err = sock intr errno(timeo); /* 如 果 有 未 处 理 的 信号 ， 则 返回 失败 ， 中 断 了 连接 
wf if (signal pending (current)) goto out; } /* 连接 被 关闭 了 。 原 因 可 能 是 对 端 
RST， 超 时 等 
过 if (sk->sk state == TCP CLOSE) goto sock error; /* 至 此 ， 连 接 成 功 
A sock->state = SS _ CONNECTED; err = 0;out: release sock(sk);return err;sock error: err = sock error(sk) ? : -ECONNABORTED; sock->state = SS_ UNCONNECTED; if {= 
接 下 来 ， 就 需要 进入 TCP 协 议 自 定义 的 connect 函 数 tcp_v4_connect 了 ， 代 码 如 下 : 
tcp_v4_connect 了 , 代码 如 下 : 
int tcp v4 connect (struct sock *sk, struct sockaddr *uaddr, int addr len){ struct sockaddr in *usin = (struct sockaddr in *)uaddr; struct inet sock *inet = inet sk(sk); 


*/ if (addr len < sizeof(struct sockaddr in)) return -EINVAL; 


*F if (usin->sin family != AF_INET) return -EAFNOSUPPORT; 


下 nexthop = daddr = usin->sin addr.s addr; /* 获得 

IP 选 项 

志 光 inet opt = rcu dereference protected (inet->inet opt, 

IP 选 项 

& if (inet opt && inet opt->opt.srr) { /* 车 地 址 为 

0， 则 返回 错误 

家 六 if (!daddr) return -EINVAL; Ld 因为 严格 源 路 由 的 


工 P 选 项 ， 所 以 下 一 跳 要 设置 为 选项 中 的 第 一 跳 地 址 


nexthop = inet opt->opt.faddr; } /* 设置 源 端口 和 目的 端口 


/* 协议 族 类 型 检查 


/* 设置 下 一 跳 和 目的 地 址 


sock owned by user (sk)); 


/* 如 果 有 严格 源 路 由 的 


7 orig _ sport = inet->inet sport; orig dport = usin->sin port; fl14 = &inet->cork.fl.u.ip47 /* 查找 路 由 


RA rt = ip route connect (f14, nexthop, inet->inet saddr, RT _ CONN FLAGS (sk), sk->sk bound dev if， IPPROTO_ TCP, orig sport, orig_ 
率 光 if (IS ERR(rt)) { err = PTR ERR(rt); if (err == -ENETUNREACH) IP_INC STATS BH(sock net (sk), IPSTATS MIB OUTNOROUTES); return err; 2* 
wf if (rt->rt flags & (RTCF MULTICAST | RTCF BROADCAST)) { ip rt put (et}s return -ENETUNREACH; } /* 如 果 没 有 


工 P 选 项 或 没有 设置 严格 路 由 ， 那 么 目的 地 址 即 为 路 由 结果 的 目的 地 址 


A if (!inet opt || !inet opt->opt.srr) daddr = f14->daddr; /* 如 果 没有 设置 源 地 址 ， 则 使 用 路 由 结果 的 源 地 址 
bi if (!inet->inet saddr) inet->inet saddr = f14->saddr; /* 套 接 字 的 接收 地 址 即 为 源 地 址 
Rf inet->inet rcv saddr = inet->inet saddr; ;| 车 保存 的 


了 TCP 选项 有 时 间 蕉 ， 并 且 目 的 地 址 与 要 连接 的 地 址 不 | 





则 需要 重 置 时 间 蕉 及 相关 变量 


内 if (tp->rx opt.ts recent stamp && inet->inet daddr != dadqr) { /* Reset inherited state */ tp->rx opt.ts recent = 0; tp->rx opt.ts recent stam 





则 尝试 从 对 端 


Peer 中 获得 时 间 玲 信息 


a if (tcp death row.sysctl tw recycle && !tp->rx opt.ts recent stamp && f14->daddr == daddr) { struct inet peer *peer = rt get peer(rt, f14->daddr); /* 妇 
A if (peer) { inet peer refcheck (peer); /* 如 果 对 端 保存 的 时 间 戴 信息 还 没有 过 期 
本 if ((u32)get seconds() - peer->tcp ts_stamp <= TCP PAWS MSL) { EA 利用 对 端 保 存 的 时 间 戴 信息 初始 化 当前 套 接 字 的 时 间 稚 选项 

*/ tp->rx opt.ts recent stamp = peer->tcp ts stamp; tp->rx opt.ts recent = peer->tcp ts; } 下 } /* 设置 目的 端口 和 地 
#/ inet->inet dport = usin->sin port; inet->inet daddr = daddr; /二 说 村 


工 P 头 的 选项 长 度 


of inet csk(sk)->icsk ext hdr len = 0; if (inet opt) inet csk(sk)->icsk ext hdr len = inet opt->opt.optlen; /* 初始 化 
MSS */ tp->rx opt.mss clamp = TCP MSS DEFAULT; /* 设置 
了 TCP 的 状态 为 


SYN_SENT， 即 发 送 了 


Syn 包 


本 tcp set state (SK，TCP SYN SENT); /* 将 套 接 字 加 入 到 


hash 表 中 ， 并 分 配 源 端 口 


去 / err = inet hash connect (gtcp death row, sk); if (exrr) goto failure; /* 检查 源 端口 或 目的 端口 是 否 发 生 了 变化 ， 如 果 发 生 了 变化 则 重新 查找 路 由 
bd rt = ip route newports(f14, rt, orig sport, orig dport, inet->inet sport, inet->inet dport, sk); if (IS ERR(rt)) { err = PTR ERR (rt)? 5 
GSO 功 能 了 


wd sk->sk gso type = SKB GSO TCPV4; sk setup caps(sk, &rt->dst); /* 如 果 没有 设置 初始 的 序列 号 ， 则 根据 双方 地 址 ， 随 机 生成 端口 


*/ if (!tp->write seq) 


tp->write seq = secure tcp sequence number (inet->inet saddr, 


inet id, 该 


工 D 用 于 生成 


工 P 报 文 的 


ID 值 


*/ inet->inet id = tp->write seq ^ jiffies; /* 一 切 准 备 工作 完毕 ， 


tcp_connect 生 成 


SYN 报 文 并 发 送 


*/ err = tcp_ connect (sk); rt = NULL; if (err) goto failure; return 0;failure: /* 


inet->inet daddr, 


* This unhashes the socket and releases the local port, 


* if necessa 

















下 面 来 分 析 tcp_connect， 看 看 内 核 是 如 何 发 送 SYN 包 的 ， 代 码 如 下 : 














int tcP_connect (struct sock *sk){ struct tcep sock *tp = tcp sk(sk); struct sk buff *buff; int err; /* 初始 化 
TCP 连接 控制 块 

a tcp_connect init (sk); /* 申请 报 文 内 存 

*/ buff = alloc skb fclone (MAX TCP HEADER + 15, sk->sk allocation); if (unlikely (buff == NULL)) 
TCP 选项 ， 所 以 直接 在 

SKb 的 首部 保 

留 

了 TCP 协 议 的 最 大 长 度 ， 从 而 保证 了 足够 的 空间 ， 避 免 重新 分 配 内 存 。 

/* 初始 化 报 文 


Wi Skb reserve (buff, MAX TCP HEADER); tp->snd nxt = tp->write seq; 


ee tcp init nondata skb(buff, tp->write seqt+, TCPHDR SYN); TCP_ECN_ send syn(sk, buff); /* 设置 


了 TCP 控制 块 相关 的 发 送 变 量 ， 并 发 送 该 


SYN 报 文 


eA TCP_SKB CB (buff) ->when = tcp time stamp; 


tp->retrans stamp = TCP_ SKB CB (buff)->when; 


skb header release (buff); 


TCP 套 接 字 对 应 的 重 传 定时 器 


RA inet csk reset xmit timer(sk, ICSK TIME RETRANS, 


inet csk(sk)->icsk rto, TCP RTO MAX); return 0;} 


return -ENOBUFS; 


/* 目前 我 们 不 知道 后 面 会 填充 哪些 


_ tcp add write queue taill(sk, buff); 


sk->sk w 























至 此 ，TCP 的 连接 过 程 已 经 分 析 完 毕 ， 民 


如 








涉及 的 某 些 过 程 会 在 后 面 进行 具体 分 析 。 























12.4 服务 器 端 连接 过 程 


12.4.1 listen 的 使 用 


服务 器 端 用 listen 来 监听 端口 ， 其 原型 为 : 





#include <sys/types .h> /* See NOTES */ 
#include <sys/socket.h> 
int listen(int sockfd, int backlog); 





其 中 的 参数 解释 如 下 : 





参数 int sockfd: 成 功 创建 的 TCP 套 接 字 。 





“int backlog: 定义 TCP 未 处 理 连接 的 队列 长 度 。 该 队列 虽然 已 经 完成 了 三 次 握手 ， 但 服务 器 端 还 没 
有 执行 accept 的 连接 。APUE 中 说 ，backlog 只 是 一 个 提示 ， 具 体 的 数值 实际 上 是 由 系统 来 决定 的 。 后 面 
会 通过 学 习 内 核 源码 来 确定 这 一 点 。 








函数 的 返回 值 为 0， 表 示 成 功 ，-1 表 示 失 败 。 


12.4.2 listen 的 源码 分 析 


listen 的 源码 入 口 位 于 socket.c， 代 码 如 下 : 








SYSCALL DEFINE2(listen, int, fd, int, backlog){ struct socket *sock; int err, fput needed; int somaxconn; 


SOCket 结 构 
wy sock = sockfd lookup light (fd, &err, é&fput needed); if (sock) { /* 得 到 系统 设置 的 最 大 未 处 理 连接 队列 长 度 
somaxconn = sock net (sock->sk)->core.sysctl somaxconn; js 如 果 用 户 指定 的 参数 


统 最 大 值 ， 则 使 用 系统 最 大 值 





*/ if ((unsigned)backlog > somaxconn)backlog = somaxconn; /* 进行 安全 性 检查 


/* 通过 检查 后 ， 就 调用 指定 协议 族 的 


4 err = security socket listen(sock, backlog); 


listen 实 现 函 数 


*/ if (!err) 


err = sock->ops->listen(sock, backlog); fput light (sock->file, fput needed); 


/* 从 文件 描述 符 得 到 


} return err;} 





AF_INET 协 议 族 的 listen 实 现 函 数 为 inet_listen， 代 码 如 下 : 





int inet listen(struct socket *sock, int backlog){ struct sock *sk = sock->sk; unsigned char old state; int err; lock sock(sk); err = -EINVAL; 
bd if (sock->state != SS UNCONNECTED || sock->type != SOCK STREAM) goto out; /* 得 到 之 前 的 
了 TCP 连接 状态 
A old state = sk->sk state; /* 如 果 之 前 的 状态 不 是 关闭 或 监听 ， 则 返回 错误 
*/ if (!((1 << old state) & (TCPF CLOSE | TCPF LISTEN))) goto out; A 经 过 前 面 的 状态 过 滤 ， 这 里 只 可 能 是 关闭 或 监听 状态 。 
如 果 当 前 已 经 是 监听 状态 了 ， 那 么 我 们 只 须 改变 
back1log 的 值 ; 
如 果 是 关闭 状态 ， 则 需要 真正 地 启动 监听 操作 。 
*/ if (old state != TCP LISTEN) { err = inet csk listen start(sk, backlog); if (err) goto out; } /* 更 新 
backlog 的 值 


Sk->sk max ack backlog = backlog; err = 0;out: release sock (sk); return err:} 


/* 如 果 套 接 字 状态 




















接 下 来 进入 inet_csk listen_start， 代 码 如 下 : 





int inet csk listen start(struct sock *sk, const int nr table entries){ Struct inet sock *inet = inet sk(sk); 


*/ int rc = reqsk queue alloc(&icsk->icsk accept queue, nr table entries); if (rc != 0) return rc; 


*/ Sk->sk max ack backlog = sk->sk ack backlog = 0; inet csk delack init (sk); /A* 


虽然 这 里 是 先 将 连接 的 状态 设 为 了 监听 状态 ， 看 似 有 一 个 竞争 时 间 窗口 。 但 实际 上 只 有 在 





get port 
成 功 以 后 ， 该 套 接 字 才 被 加 入 到 哈 希 表 中 一 从 系统 的 角度 看 ， 套 接 字 加 入 到 哈 希 表 中 后 ， 才 会 真正 


处 于 监听 状态 ， 可 以 接受 连接 请 求 了 。 因 此 实际 上 并 没有 竞争 发 生 


sy Sk->sk state = TCP LISTEN; /* 使 用 


struct inet connection sock *icsk = inet csk(sk); 


/* 初始 化 工作 


/* 为 连接 i 


get_PoTt 进 行 端口 绑 定 


if (!sk->sk prot->get port(sk, inet->inet num)) { /* 设置 源 端口 

Ee inet->inet sport = htons (inet->inet num); /* 清除 路 由 缓存 

过 sk dst reset (sk) /* 将 套 接 字 加 入 到 哈 硕 表 中 ， 这 时 才 可 以 接受 新 连接 

*/sk->sk prot->hash (sk); return 0; } /* 绑 定 端口 失败 ， 则 设置 连接 未 关闭 状态 

bd sk->sk_state = TCP CLOSE; /* 释放 连接 请 求 队列 空间 

六 _ reqsk queue destroy(&icsk->icsk accept queue); return -EADDRINUSE;} 





现在 服务 器 端 已 经 处 于 监听 状态 ， 可 以 接收 客户 端的 连接 请 求 了 。 同 时 ， 











Th 





接 使 

















其 值 作为 


己 连 接 队列 的 长 度 了 。 








通过 源码 跟踪 ， 也 可 以 发 现在 第 二 个 参数 不 超过 系统 限制 的 最 大 值 的 情况 下 ， 内 核 已 





Ls; 


12.4.3 accept 的 使 用 





accept 用 于 从 指定 套 接 字 的 连接 队列 中 取出 第 一 个 连接 ， 并 返回 一 个 新 的 套 接 字 用 于 与 客户 端 进行 
通信 ， 示 例 代 码 如 下 : 





#include <sys/types.h> /* See NOTES */ 

#include <sys/socket.h> 

int accept (int sockfd, struct sockaddr *addr, socklen t *addrlen); 
int accept4(int sockfd, struct sockaddr *addr, 

socklen t *addrlen, int flags); 





其 中 的 参数 解释 如 下 : 


-int sockfd: 处 于 监听 状态 的 套 接 字 。 


“struct sockaddr*addr: 用 于 保存 对 端的 地 址 信息 。 





'Socklen t*addrlen: 是 一 个 输入 输出 值 。 调 用 者 将 其 初始 化 为 addr 绥 存 的 大 小 ，accept 返 回 时 ， 会 
将 其 设置 为 addr 的 大 小 。 


"int flags: 是 新 引入 的 系统 调用 accept4 的 标志 位 ; 目前 支持 SOCK NONBLOCK 和 
SOCK_CLOEXEC。 


关于 返回 值 ， 若 执行 成 功 ， 则 返回 一 个 非 负 的 文件 描述 符 ; 着 失败 则 返回 -1。 


© 注意 ” 若 不 关心 对 端 地 址 信息 ， 则 可 以 将 addr 和 addrlen 设 置 为 NULL。 


12.4.4 _ accept 的 源码 分 析 








accept 的 源码 入 








位 于 文件 socket.c， 代 码 如 下 : 











SYSCALL DEFINE3(accept, int, fd, struct sockaddr _user *, upeer sockaddr, 


int _ user *, upeer addrlen){ 


return sys accept4 (fd, upeer sockaddr, upeer addrlen, 0);} 

















进入 sys_accept4， 代 码 如 下 : 











SYSCALL DEFINE4 (accept4, int, fd, struct sockaddr _user *, upeer sockaddr, int _user *, upeer addrlen, int, flags){ struct socket *sock, *newsock; struct file *n 
*/ if (flags & ~ (SOCK CLOEXEC | SOCK NONBLOCK)) return -EINVAL; /* 保证 设置 的 非 阻塞 标志 
SOCK NONBLOCK 与 
O_NONBLOCK 相 同 
*y if (SOCK NONBLOCK != O NONBLOCK && (flags & SOCK NONBLOCK)) flags = (flags & ~SOCK NONBLOCK) | O_ NONBLOCK; /* 通过 文件 描述 符 获得 
SOCket 结 构 
*/ sock = sockfd lookup light (fd, &err, &fput needed); if (!sock) goto out; err = -ENFILE; /* 申请 一 个 新 的 
SOCKet 结构 
*/ newsock = sock alloc(); if (!newsock) goto out put; /* 新 的 
SOCket 的 类 型 和 操作 函数 与 监听 
SOCKet 一 至 
本 六 newsock->type = sock->type; newsock->ops = sock->ops; 
增加 该 套 接 字模 块 的 引用 计数 。 这 是 因为 这 个 套 接 字 模块 可 能 不 是 
Linux 内 核 内 置 的 ， 
为 了 保证 在 套 接 字 的 使 用 过 程 中 ， 访 模块 不 会 被 意外 务 载 ， 所 以 ， 在 创建 套 接 字 时 ， 需 要 增加 相应 
的 模块 计数 
六 __ module get (newsock->ops->owner); /* 为 新 的 
SOCKet 类 型 ， 申 请 一 个 新 的 文件 描述 符 
*/ newfd = sock alloc file(newsock, &newfile, flags); if (unlikely(newfd < 0)) { err = newfd; sock release (newsock); goto out put; 要 2 
aCCept 操 作 进行 安全 性 检查 
*/ err = security socket accept (sock, newsock); if (err) goto out fd” /* 执行 协议 族 的 
aCCept 操 作 函 数 
a err = sock->ops->accept (sock, newsock, sock->file->f flags); if (err < 0) goto out fd /* 用 户 想 获得 对 端 地 址 
二 if (upeer sockaddr) { /* 获得 对 端 地址 
*/ if (newsock->ops->getname (newsock, (struct sockaddr *) &address, &len, 2) < 0) { err = -ECONNABORTED; goto out fq; } 
yf err = move addr to user((struct sockaddr *)&address, len, upeer sockaddr, upeer addrlen); i ‘(BEr < O) goto out fq; } /* 将 文件 描述 各 


newfd 和 文件 管理 结构 


Dewfi le 安装 到 文件 表 中 


*/fd install (newfd，newfile);  /* 此 时 ， 已 保证 


accept 成 功 执 行 ， 将 


Dewfd 赋 给 


err， 并 在 后 面 返回 


err */ err = newfd;out put: fput light (sock->file, fput needed);out: return err;out fd: fput (newfile); put unused fd (newfd); goto out put;} 








对 于 AF_INET 协 议 族 ，accept 的 实现 函数 为 inet_accept， 代 码 如 下 : 











int inet accept (struct socket *sock, struct socket *newsock, int flags){ struct sock *skl = sock->sk; int err = -EINVAL; /* 调用 具体 协议 的 


aCCept 操 作 ， 并 得 到 新 的 


SOCK 结 构 

本 struct sock *sk2 = skl->sk prot->accept (skl, flags, &err); if (!sk2) goto do err; /* 锁 住 新 的 
Sk2 */ lock sock(sk2); /* 记录 

RFS: 





可 sock rps_ record flow(Sk2) 7 WARN ON(!((1 << sk2->sk state) & (TCPF ESTABLISHED | TCPF CLOSE WAIT | TCPF CLOSE))); /* 将 新 的 
SOCk 与 调用 者 传递 的 

SOCket 关 联 起 来 

可 sock graft (sk2, newsock); /* 设置 

SOCket 为 连接 状态 

*/ newsock->state = SS_CONNECTED; err = 0; /* 释放 

SK2 的 控制 权 

起 才 release sock(sk2); do err: return err;} 























对 于 TCP 协 议 来 说 ， 其 accept 实 现 函 数 如 下 : 





struct sock *inet csk accept (struct sock *sk, int flags, int *err){ struct inet connection sock *icsk = inet csk(sk); struct sock *newsk; int errors /* 获得 
Sk 的 控制 权 
* lock sock (sk); error = -EINVAL; /* sk, 即 


了 TCP 连接 ， 若 不 是 监听 状态 则 报错 


*/ if (sk->sk state != TCP LISTEN) goto out err; if (reqsk queue empty(&icsk->icsk accept queue)) { /* 已 连接 队列 为 空 
4 /* 得 到 
Sk 的 超时 时 间 


*/ long timeo = sock rcvtimeo(sk, flags & O NONBLOCK); /* If this is a non blocking socket don't sleep */ error = -EAGAIN; /* 如 果 超 时 为 


0， 即 非 阻塞 ， 则 报错 退出 


*/ if (!timeo) goto out err; /* 以 


timeo 为 超时 时 间 ， 等 待 一 个 新 的 连接 


error = inet csk wait for connect (sk, timeo); if (error) goto out err; } /* 得 到 新 的 


sock */ newsk = reqsk queue get child(g&icsk->icsk accept queue, sk); WARN ON (newsk->sk state == TCP_ SYN RECV);out: /* 释放 


Sk 的 控制 权 ， 并 返回 新 建 连接 


newsk */ release sock (sk); return newsk;out err: newsk = NULL; “er = OrPOr goto out;} 





12.$_TCP 三 次 握手 的 实现 分 析 


前 面 两 节 分 别 从 客户 端 和 服务 器 端的 系统 调用 的 角度 ， 来 分 析 和 学 习 TCP 的 连接 过 程 。 本 节 将 从 
TCP 三 次 握手 的 数据 包 交 互 过 程 ， 来 研究 TCP 连 接 的 建立 。 如 果 不 熟 悉 TCP 握 手 的 三 个 数据 包 ， 则 请 自 
行 阅读 相关 材料 。 





三 次 握手 的 过 程 如 图 12-1 所 示 。 


客户 端 服务 需 端 
关闭 状态 监听 状态 
发 送 syn 包 收 到 syn 包 
连接 状态 连接 状态 





图 12-1 TCP 三 次 握手 的 过 程 


12.5.1 SYN 包 的 发 送 


SYN 包 是 指 客户 端 主动 建立 一 个 TCP 新 连接 的 第 一 个 包 ， 其 TCP 标 志 为 SYN， 表 示 同 步 TCP 的 序列 号 。 









































SYN 包 的 发 送 是 在 tcp_connect 函 数 中 完成 的 ， 下 面 对 SYN 包 的 构建 做 进一步 分 析 。 在 tcpp_connect 函 数 中 ， 通 过 调用 tcp_init_nondata_skb (buff，tp- 





>write seq++，TCPHDR_SYN) 来 完成 SYN 包 的 构建 ， 示 例 代 码 如 下 : 














static void tcp init nondata skb (struct sk buff *skb, u32 seq, u8 flags){ /* 设置 为 


CHECKSUM _ PARTIAL， 表示 需要 计算 


了 TCP 校 验 和 

A skb->ip_summed = CHECKSUM PARTIAL; /* 初始 化 校 验 和 信息 
A skb->csum = 0; /* TCP_SKB_CB 是 一 个 宏 ， 用 于 将 
Skb->cb 转 换 为 

TCP 的 控制 块 





*/ TCP_SKB CB (skb)->tcp flags = flags; /* 重 置 控制 块 的 

SACK 标 志 位 

sy TCP_SKB CB (skb) ->sacked = 0; /* 初始 化 

Skb 的 

GSO */ Skb shinfo(skb)->gso segs = 1; Skb shinfo(skb)->gso size = 0; Skb shinfo(skb)->gso type = 0; /* 设置 
TCP 的 序列 号 

.六 TCP_SKB CB (skb) ->seq = seq; /* 如 果 是 

SYN 或 

FIN 包 ， 则 增加 

了 TCP 序列 号 

ff if (flags & (TCPHDR SYN | TCPHDR FIN)) Seqt++? /* 设置 结束 序列 号 


*/ TCP_SKB CB (skb)->end seq = seq;} 





从 源码 中 可 以 发 现 ， 这 个 函数 只 是 设置 TCP 控 制 块 的 序列 号 和 标志 ， 并 没有 真 了 





























tcp_init nondata skb 和 tcp_transmit skb 之 间 再 没有 任何 与 构建 数据 包 相 关 的 代码 了 。 
道理 。tcp_transmit skb 作 为 TCP 发 送 函 数 的 入 口 ， 统 一 实现 了 TCP 数 据 包 的 构建 
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下 面 是 其 中 用 于 构造 TCP 数 据 包 的 相关 代码 : 











B 么 


E 构 建 TCP 数 据 包 。 屠 么 ， 让 我 们 回 过 头 来 看 tcp_connect， 但 是 在 











也 只 剩 下 一 个 可 能 ， 即 在 tcp_transmit_skb 中 实现 数据 包 的 构 于 


E 


Ey 


这 样 也 合乎 





/* 为 


TCP 报 文 头 部 保存 空间 


*/skb push (skb，tcp _header size);/* 重 置 


TCP 报 文 头 指针 


*/skb reset transport header (skb);/* 设置 


Skb 的 所 有 者 为 


Sk， 同 时 增加 


Sk 的 写 缓存 的 使 用 统计 


*/skb set _ owner w(skb, sk);/* 得 到 


TCP 报 文 头 的 内 存 指针 ， 开 始 构建 





了 TCP 的 报 文 头 部 

yw/ /* 这 里 设置 了 口 、 目 的 端口 、 序 列 号 、 确 认 序列 号 、 包 长 及 标志 位 

*/th = tcp hdr (skb) ;th->source = inet->inet sport;th->dest = inet->inet dport;th->seq = htonl (tcb->seq) ;th->ack seq = htonl (tp->rcv nxt);*(((_ 
SYN 包 ， 则 


TCP 窗 口 不 会 被 扩展 


*/if (unlikely(tcb->tcp flags & TCPHDR SYN)) { /* RFC1323: The window in SYN & SYN/ACK segments * is never scaled. A th->window = htons (min (tp->rcv wnd, 65535U));} 


了 CP 的 校 验 和 与 紧急 提 





0 */th->check = 0;th->urg ptr 三 07 /* 检查 是 否 需要 设置 紧急 指针 
*/if (unlikely(tcp urg mode (tp) && before(tcb->seq, tp->snd up))) { if (before (tp->snd_ up, tcb->seq + 0x10000)) { th->urg ptr = htons (tp->snd up - tcb->seq); th= 
TCP 选项 部 分 


*/tcp options write(( be32 *) (th + 1), tp, &opts);/* 计算 


了 CP 的 校 验 和 


*/icsk->icsk af ops->send check (sk，skb);/* 完成 了 


了 TCP 数据 包 的 构建 ， 将 数据 包 交 给 


IP 层 


*/err = icsk->icsk af ops->queue xmit (skb, &inet->cork.f1); 






































从 上 面 的 代码 中 ， 我 们 可 以 进一步 领会 Linux 内 核 协 议 栈 的 数据 包 传 输 机 制 一 每 一 层 都 专注 于 自己 的 工作 。 对 于 TCP 传 输 层 来 说 ， 只 须 负责 在 skb 中 构建 自己 的 
首部 ， 然 后 将 skb 数 据 包 传递 给 外 层 做 进一步 的 处 理 即 可 。 












































12.5.2 ”接收 SYN 包 ， 发 送 SYN+ACK 包 














为 了 跟踪 SYN 包 的 接收 流程 ， 首 先进 入 内 核 并 接收 发 给 本 机 数据 包 的 入 口 ijp_local_deliver_finish， 代 码 如 下 : 

















static int ip local deliver finish(struct sk buff *skb){ /* 得 到 设备 的 网 络 空间 


a struct net *net = dev net (skb->dev); /* 取 走 网 络 层 报 文 头 部 


*/ _ skb pull(skb, ip hdrlen (skb)); /* 重 置 传 文 头 部 





A Skb reset transport header (skb); rcu read lock(); /* 得 到 传输 层 





A int protocol = ip hdr (skb)->protocol; int hash, raw; const struct net protocol *ipprot; resubmit: /* 将 数据 包 传递 给 对 应 的 原始 套 接 字 

raw = raw local deliver(skb, protocol); /* 得 到 协议 表 的 桶 索引 

二 hash = protocol & (MAX INET PROTOS - 1); /* 得 到 注册 协议 

生效 ipprot = rcu dereference (inet_Protos [hash]) if (ipprot != NULL) { int ret; if (!net eq(net, &init net) && !ipprot->netns ok) { 

X 下 rm 策略 检查 

if (!ipprot->no policy) { if (!xfrm4 policy check (NULL, XFRM POLICY IN, skb)) { kfree skb (skb); goto out; 

谭 天 ret = ipprot->handler (skb); if (ret < 0) 1{ protocol = -ret; goto resubmit; } IP_INC STATS BH(net, 
if (!raw) { if (xfrm4 policy check (NULL, XFRM POLICY IN, skb)) { /* 没有 任何 已 注册 的 网 络 协议 可 以 处 理 这 个 数据 包 ， 因 此 回复 

ICMP proto unreachable */ IP_INC STATS BH (net, IPSTATS MIB INUNKNOWNPROTOS); icmp send (skb, ICMP DEST UNREACH, ICMP 

















TCP 协 议 在 系统 初始 化 时 ， 会 将 对 应 的 处 理 函 数 注册 到 inet_protos 上 ， 接 下 来 进入 TCP 的 处 理 函 数 tcpp_v4_rcv 中 ， 代 码 如 下 : 














int tcp v4 rcv(struct sk buff *skb){ const struct iphdr *iph; const struct tcphdr *th; Struct sock *sk; int ret; struct net xnet = dev net (skb->dev); /* 如 果 数据 
QFOP 掉 
汪汪 if (skb->pkt type != PACKET HOST) goto discard it; /* Count it even if it's bad */ TCP_INC STATS BH(net, TCP MIB INSEGS); /* 数据 包 至 少 还 有 一 个 


CP 报 文 头 部 长 度 


%/ if (!pskb may pull(skb, sizeof(struct tcphdr))) goto discard it; /* 得 到 
TCP 报 文 头 部 
*/ th = tcp hdr (skb); /* 检查 


了 TCP 的 数据 偏 黎 ， 至 少 要 比 头 部 大 


*/ if (th->doff < sizeof (struct tcphdr) / 4) goto bad packet; /* 检查 数据 段 长 度 
*/ if (!pskb may pull (skb, th->doff * 4)) goto discard it; /* 计算 校 验 和 
家 if (!skb csum_unnecessary(skb) && tcp v4 checksum init (skb) ) goto bad packet; /* 重新 得 到 


TCP 头 部 。 因 为 前 面 的 代码 可 能 会 重新 申请 


skb. 


*/ th = tcp hdr (skb); /* 得 到 


工 P 头 部 


ad iph = ip hdr (skb); /* 设置 


了 TCP 控制 块 的 序列 号 ， 结 束 序列 号 ， 确 认 序 列 号 等 


RA TCP_SKB CB (skb) ->seq = ntoh]l (th->seq); TCP_SKB CB (skb) ->end seq = (TCP SKB CB(skb)->seq + th->syn + th->fin + skb->len - th->doff * 4); TCP_SKB CB (skb)->ack seq = 


SOCk 结 构 。 


这 里 先 对 已 经 连接 的 


SOCK 进 行 查找 ， 然 后 对 监听 的 


SOCK 进 行 查找 


*/ sk = _ inet lookup skbl(&tcp hashinfo, skb, th->source, th->dest); if (!sk) goto no tcp socket;process: /* 如 果 


SOCK 处 于 


了 TIME WRAIT 状 态 ， 则 跳 转 到 


do time wait */ if (sk->sk state == TCP_ TIME WAIT) goto do time wait; /* 如 果 数 据 包 的 

了 TTL 小 于 设置 的 

TTL 阅 值 ， 则 丢弃 

*/ if (unlikely (iph->ttl < inet sk(sk)->min tt1)) { NET_INC_STATS BH(net, LINUX MIB TCPMINTTLDROP); goto discard and relse; F /* xfrm 策 略 失败 
if (!xfrm4 policy check(sk, XFRM POLICY IN, skb)) goto discard and relse; /* 虽然 函数 的 名 字 为 


reSet 重 置 ， 但 实际 上 是 释放 了 





netfilter 的 相关 资源 

4 nf reset (skb); /* 执行 

SOCKket 过 滤器 

人 if (sk filter(sk, skb)) goto discard and relse; /* 重 置 数据 包 的 网 卡 
二 skb->dev = NULL; /* 镇 住 


SOCK， 获 得 控制 权 


过 bh lock sock nested (sk) ret = 0F if (!sock owned by user(sk)) { /* 如 果 用户 进程 没有 再 使 用 这 个 


sock */ Pa 


DMA 来 做 数据 包 拷贝 ， 实 现 


TCP receive offload*/#ifdef CONFIG NET DMA struct tcp sock *tp = tcp sk(sk); if (!tp->ucopy.dma chan && tp->ucopy.pinned list) tp->ucopy.dma chan = dma fin 
prequeue 中 
Sf if (!tcp prequeue(sk, skb)) { /* 如 果 放 到 


prequeue 中 失败 ， 则 只 能 即时 处 理 该 数据 包 


*/ ret = tcp v4 do rcv(sk, skb); } } A else if 的 时 候 ， 意 味 着 用 户 进程 正在 使 用 这 个 套 接 字 。 


那么 就 把 数据 包 保存 到 


backlog 中 . 
# } else if (unlikely(sk add backlog(sk, skb))) { bh unlock sock (sk); NET_INC_ STATS BH(net, LINUX MIB TCPBACKLOGDROP); goto discard and relse; } 
Sk 的 控制 权 
A sock put (sk); return ret;no tcp socket: /* 车 没有 找到 对 应 的 
了 TCP 套 接 字 ， 并 且 


xX 下 rm 策略 检测 失败 ， 则 丢弃 数据 包 


if (!xfrm4 policy check (NULL, XFRM POLICY IN, skb)) goto discard it; /* 检查 是 否 数据 包 长 度 出 错 ， 或 者 是 校 验 和 出 错 
*/ if (skb->len < (th->doff << 2) || tcp checksum complete(skb)) { bad packet: TCP_INC STATS BH(net, TCP MIB INERRS); F BLSe /* 车 数据 包 未 出 错 ， 但 也 没有 匹配 的 套 接 字 ， 则 
TCP RESET */ tcp v4 send reset (NULL, skb); }discard it: /* Discard frame. */ kfree skb (skb); return 0;discard and relse: sock put (sk); goto discard it;do ti 


了 TIME WAIT 状 态 的 数据 包 处 理 ， 


*/ /* 在 此 省 略 了 这 些 代码 分 析 


ey 























根据 上 面 的 分 析 可 知 ， 对 于 SYN 包 的 处 理 ， 还 需要 进入 函数 tcp_v4_do_rcev， 代 码 如 下 : 


























int tcp v4 do rcv(struct sock *sk, struct sk buff *skb){ struct sock *rsk; #ifdef CONFIG TCP MD5SIG /* 进行 


TCP 的 


MD5 检 查 , 是 


了 TCP 的 一 个 安全 检查 


yf if (tcp v4_ inbound md5 hash (sk, skb) goto discard; #endif if (sk->sk state == TCP ESTABLISHED) { /* Fast path */ /* 处 理 已 连接 的 数据 包 流程 


小 /* 如 果 数 据 包 与 套 接 字 的 


rXhash 不 同 ， 则 重 置 套 接 字 的 


rxhash*/ Sock rps save rxhash(sk, skb); /* 进入 已 连接 

TCP 的 处 理 函 数 

*/ if (tcp rcv established(sk, skb, tcp hdr(skb), skb->len)) { rsk = sk; goto reset; return 0; } /* 运行 到 这 里 ， 则 表明 该 
了 TCP 为 非 连接 状态 


*/ /* 检查 数据 包 长 度 和 


了 TCP 校 验 值 


*/ if (skb->len < tcp hdrlen(skb) || tcp checksum complete (skb)) goto csum err; if (sk->sk state == TCP LISTEN) { /* 连接 处 于 监听 状态 ， 这 是 我 们 要 跟踪 的 流程 


< i 处 理 连接 请 求 ， 即 处 理 


SYN 包 。 作 为 第 一 个 


SYN 包 请 求 ， 服 务 端 只 有 


一 个 监听 


SOCKk， 所 以 这 里 返回 的 


nsk 实 际 上 就 是 


Sk. 


这 里 就 不 跟踪 


tcp v4 hnd reqT. 


要 struct sock *nsk = tcp v4 hnd reql(sk, skb); if (!nsk) goto discard; 4f (nsk l= sk} { /* 为 


SYN 请 求生 成 了 新 的 


SOCk 结 构 ， 自 然 需要 重新 做 








RFS hash */ sock rps save rxhash(nsk, skb); /* 处 理子 
sock */ if (tcp child process(sk, nsk, skb)) { rsk = nsk; goto reset; } return 0; $k } /* 根据 状态 处 理 数据 包 
/ if (tcp rcv state process(sk, skb, tcp hdr (skb), skb->len)) { rsk = sk; goto reset; /* 省 略 其 余 的 不 相干 的 代码 
*/} 
进入 tcp_rcv_state process， 我 们 截取 部 分 相关 的 代码 : 
Switch (sk->sk_state) {/* SOcK 处 于 监听 状态 
*/case TCP _ LISTEN: /* 监听 状态 不 应 收 到 
ack 包 
py if (th->ack) return 1; /* 丢弃 
RST 数 据 包 
*/ if (th->rst) goto discard; /* 收 到 
SYN 请 求 包 
*/if (th->syn) { /* 车 设置 了 
FIN 结 束 标 志 ， 则 丢弃 包 
yp | goto discard; /* 调用 对 应 的 处 理 连接 请 求 的 回调 函数 
*/ if (icsk->icsk af ops->conn request (sk, skb) < 0) return 1; /* SYN 包 处 理 完毕 ， 释 放 数 据 包 
*/ kfree skb (skb); return 0; 上 











对 于 IPv4 的 TCP 来 说 ， 处 理 连 接 请 求 的 函数 是 tep_v4_conn request， 代 码 如 下 : 





int tcp v4 conn request (Struct sock g*sk, struct sk buff *skb){ struct tcp extend values tmp ext; struct tcp options received tmp opt; 


const u8 *hash location; 


stru 


*/ if (skb rtable(skb)->rt flags & (RTCF BROADCAST | RTCF MULTICAST)) goto drop; /* TW buckets are converted to open requests without * limitations, they cons 


和 if (inet csk reqsk queue is fulll(sk) && !isn) { /* 判断 是 否 使 用 


Syn COokie， 如 不 使 用 则 丢弃 该 包 


wf/ want cookie = tcp syn flood action(sk, skb, "TCP"); if (!want cookie) goto drop; /* back1og 队 列 已 满 ， 并 且 队 列 中 已 有 足够 多 的 最 近 未 处 理 的 连接 请 求 。 则 丢弃 该 包 

*/ if (sk acceptq is full(sk) && inet csk reqsk queue young(sk) > 1) goto drop; /* 申请 一 个 请 求 

SGCKR */ req = inet reqsk alloc(&tcp request sock ops); if (!req) goto drop;#ifdef CONFIG TCP MD5SIG tecp rsk(req)->af specific = &tcp request sock ipv4 ops;#endi 
了 TCP 选项 

w/ tcp clear options (&tmp opt); tmp opt.mss clamp = TCP MSS DEFAULT; tmp opt.user mss = tp->rx opt.user mss; tcp parse options(skb, &tmp opt, &hash location, 0); 

syn cookie */ if (tmp opt.cookie Plus > 0 && tmp opt.saw tstamp && !tp->rx opt.cookie out never && (sysctl tcp cookie size > 0 || (tp->cookie va 


Syn cookie,， 但 没有 时 间 稚 选项 ， 则 清除 


了 TCP 选项 
*/ if (want cookie && !tmp opt.saw tstamp) tcp_ clear options (gtmp opt); /* 初始 化 
request sock */ tmp opt.tstamp ok = tmp opt.saw tstamp; tcp openreq init(req, &tmp opt, skb); ireq = inet rsk(req); ireq->loc addr = daddr; ireq->rmt addr = sadd 


Syn COOKie， 或 者 有 时 间 戳 选项 时 ， 如 果 请 求 表示 支持 


瑟 CN， 则 服务 端 也 设置 


ECN 标 志 


夫人 if (!want_cookie || tmp opt.tstamp ok) TCP_ECN create request (req, tcp hdr (skb)); if (want cookie) { /* 车 需要 做 


Syn COOKie， 则 产生 一 个 


COOkie 序 列 号 


*/ isn = cookie v4 init sequence(sk, skb, &req->mss); req->cookie ts = tmp opt.tstamp ok; } else if (!isn) { struct inet peer *peer = NULL; stru 


TimeWait 状 态 的 


SOCket 是 否 可 以 重用 : 


1) 该 


SOCket 支 持 时 间 检 选项 。 


2) 打开 了 


TimeWait 状 态 


SOCKet 重 用 开关 。 


3) 通过 查找 路 由 ， 获 得 对 端 





4 ) 当前 时 间 与 对 端的 上 个 时 间 礁 间 隔 小 于 


TCP_ PAWS MSL( 


60) 秒 ， 并 且 新 请 求 时间 小 于 对 端 


上 个 时 间 截 


TCP_ PAWS MSL( 


60) 秒 以 上 。 


当 同 时 满足 上 而 几 个 条 件 时 ， 则 认为 该 请 求 为 非法 请 求 


*/ if (tmp opt.saw tstamp && tcp death row.sysctl tw recycle && (dst = inet csk route reql(sk, &f14, req)) != NULL && f14.daddr = 


Syn COOKie 的 情况 下 ， 内 核对 


Syn flood 做 的 简单 防护 : 


1) 连接 队列 已 经 使 用 了 四 分 之 三 以 上 。 


2) 没有 对 端 





对 端 没有 时 间 戴 。 


3) 没有 路 由 





RTT 时 间 。 
当 同时 满足 以 上 条 件 时 ， 表 明 队列 已 接近 满 队列 ， 同 时 这 个 新 连接 可 能 还 无 法 正常 通信 ， 那 么 
就 会 放弃 这 个 请 求 
else if (!sysct1 tcp syncookies && (SYSsct1 max syn backlog - inet csk reqsk queue len (sk) < (sysct1 max syn backlog >> 2)) && 
二 站 isn = tcp v4 init_sequence (skb) ; } /* 保存 初始 序列 号 和 
Synack 发 送 时 间 
要 这 tcp rsk(req)->snt isn = isn; tcp rsk(req)->snt synack = tcp time stamp; /* 回复 
SYNACK 数 据 包 
uy if (tcp v4 send synack(sk, dst, req, (struct request values *)&tmp ext) || want cookie) goto drop and free; /* 将 


request sock 加 入 到 哈 希 表 中 


丰 玫 inet csk reqsk queue hash add(sk, req, TCP TIMEOUT INIT); return 0;drop and release: dst_ release (dst) ;drop and free: reqsk free (req) ;drop: return 0;} 








回 


这 就 是 服务 端 收 到 SYN 包 ， 并 








复 SYN+ACK 的 过 程 。 








12.$.3 ”接收 SYN+ACK 数 据 包 


客户 端 接收 SYN+ACK 数 据 包 的 流程 与 服务 器 端 类 似 ， 都 要 经 过 ip _ local deliver finish->tcp_v4 rcv->tcp_v4 do_rcv->tcp_rcv_state process， 这 里 会 根据 TCP 的 不 
同 连接 状态 ， 进 行 不 同 的 处 理 。 对 于 此 时 的 客户 端 来 说 ， 其 连接 状态 为 TCP_SYN_SENT〈 即 发 送 了 SYN 包 ) ， 其 代码 如 下 : 





























Case TCP_SYN SENT: /* 处 理 


SYN+ACK， 完 成 三 次 握手 


A queued = tcp rcv synsent state process(sk, skb, th, len); if (queued >= 0) return queued; /* Do step6 onward by hand. */ /* 处 理 
urgent 数 据 
yf tcp urg(sk, skb, th); _ kfree_ skb(skb); tcp data snd check (sk); 

















然后 进入 tcp_rcv_synsent state_process， 代 码 如 下 : 





static int tcp rcv synsent state process(struct sock *sk, struct sk buff *skb, const struct tcphdr *th, unsigned int len){ const u8 *hash location; struc 
TCP 选 项 

$f tcp parse options (skb, &tp->rx opt, &hash location, 0); /* 设置 了 

ACK 标 志 

*/ if (th->ack) { yw ro0793: * "IE the state is SYN-SENT then 率 first check the ACK bit 次 If the ACK bit is set IE SEG 


ACK 号 非法 ， 即 不 等 于 我 们 下 次 要 发 的 序列 号 ， 则 重 置 连接 


if (TCP_ SKB CB (skb)->ack seq != tp->snd nxt) goto reset and undo; /* 判断 


了 TCP 时 间 稚 是 否 合法 


*/ if (tp->rx opt.saw tstamp && tp->rx opt.rcv tsecr && !between (tp->rx opt.rcv tsecr, tp->retrans stamp, tcp time stamp)) { NET_IN 


ACK 标 志 已 经 通过 了 检查 。 这 时 ， 如 果 设 置 了 


Reset 位 ， 则 重 置 连接 


*/ 4f (th->rst) +1 tcP_reset (Sk) ? goto discard; } /* 如 果 没 有 设置 


SYN 标 志 ， 则 丢弃 该 包 


*/ if (!th->syn) goto discard and undo; /* 如 果 


TCP 套 接 字 设置 了 


ECN 标 志 ， 但 是 数据 包 没有 设置 


CE 标志 (表示 





不 支持 


TCP ECN 显 示 拥塞 通告 )， 则 清除 掉 本 端的 

EECN 标 志 ) 

二 TCP_ECN rcv_ synack(tp, th); /* 处 理 
BCk 数 据 包 ， 设 置 


了 TCP 发 送 窗口 


bid tp->snd wll = 


TCP_SKB_CB (skb) ->seq; 


TCP 窗 口 大 小 ， 是 不 考虑 


Scale 选项 的 


*/ tp->snd wnd = ntohs (th->window); 


windows Scale 选项 


/* 将 接收 端 和 接收 端的 窗口 扩展 选项 设置 为 


二 if (!tp->rx opt.wscale ok) { 


0 */ tp->rx opt.snd wscale = tp->rx opt.rcv wscale = 0; 


*/ tp->window clamp = min(tp->window clamp, 65535U); } 


/* 设置 时 间 蕉 选项 


*/ if (tp->rx opt.saw tstamp) { 


wf tp->rx opt.tstamp ok = tp->tcp header len = 


of tcp mtup init (sk); tcp sync mss(sk, icsk->icsk pmtu cookie); 


e tp->copied seq = tp->rcev nxt; if (cvp != NULL && 

本 tcp set state(sk, TCP ESTABLISHED); security inet conn established(sk, skb); 
*/ icsk->icsk af ops->rebuild header (sk); /* 下 面 对 路 由 的 

metric., 


TCP 的 阻塞 控制 和 缓存 等 进行 初始 化 


&f tcp init metrics(sk); 


tcp init congestion control (sk); 


keepalive， 则 初始 化 


keepalive 定 时 器 


*/ if (sock flag(sk, SOCK KEEPOPEN)) 


了 TCP 快速 路 径 预 测 标志 


*/ if (!tp->rx opt.snd wscale) 


SOCK 的 状态 不 是 死亡 状态 


吉 光 if (!sock flag(sk, SOCK DEAD)) { fs 夏 沟 





唤醒 等 待 进程 


Wd sk->sk_ state change (sk); /* 若 有 异步 等 待 队 列 ， 则 给 该 进程 发 送 异步 事件 
id Sk wake async (sk, SOCK WAKE IO, POLL OUT); 于 扩 
1) 有 写 操作 等 待 。 


2) 设置 了 延迟 


tcp ack(sk, skb, FLAG SLOWPATH); 


tcp init wl (tp, TCP SKB CB (skb)->seq); 


Cvp->cookie pair size > 0 && 


inet csk reset keepalive timer(sk, keepalive time when (tp)); 


_ tcp fast path onl(tp, tp->snd wnd); 


/* Ok.. it's good. Set up sequence numbers and 


/* 如 果 没 有 


/* 设置 窗口 的 最 大 值 


/* 判断 是 否 时 间 堆 选项 


sizeof (struct tcphdr) + TCPOLEN TSTAMP ALIGNED; 


tcp initialize rcv mss(sk); 


/* Remember, tcp poll() does 


tp->rx opt.cookie Plus > 0) { 


/* Make sure socket is routed, for correct metrics. 


/* Prevent spurious tcp cwnd restart() on first data * packet. 


发 送 方 没有 设置 窗口 扩展 选项 ， 则 设置 





else tp->pred flags = 0; /* 如 果 


如 果 该 套 接 字 : 


tp->advmss 


bt 


* move to established. 


not lock socket! 


int cookie size = 


ed 


/* 查找 路 由 


tp->lsn 


accept. 


3) 没有 设置 快速 

ack。 
人 if (sk->sk write pending || icsk->icsk accept queue.rskq defer accept || icsk->icsk ack.pingpong) { /* 满足 上 面条 件 之 一 ， 则 延 时 确认 

*/ /* Save one ACK. Data will be ready after * several ticks, if write pending is set. 涛 * It may be deleted, but with this feature 

eA tcp_send ack (sk); } return -1;} /* 到 此 ， 表 示 没有 

ACK 标 志 

Wx if (th->rst) { /* 如 果 没 有 

ACK 只 有 


RST， 则 丢弃 该 包 


二 goto discard and ungo; } /* 时 间 戴 检测 


*/ if (tp->rx opt.ts recent stamp && tp->rx opt.saw tstamp && tcp paws reject (gtp->rx opt, 0)) goto discard and undo; if (th->syn) { /* 车 只 有 


没有 





ACK， 则 可 能 是 同时 发 出 了 多 个 


SYN 连 接 请 求 ， 甚 至 有 可 能 是 自己 连接 自己 


/* 设置 连接 状态 为 收 到 


SYN 包 


id tcp set state(sk, TCP SYN RECV); jp 后 面 的 代码 ， 与 之 前 收 到 


SYN 包 的 流程 基本 一 致 ， 在 此 就 不 做 分 析 了 


*/ if (tp->rx opt.saw tstamp) { tp->rx opt.tstamp ok = 17 top store ts recent (te)? tp->tcp header len = sizeof (st 


SYN 也 没有 


有 RST 标 志 ， 则 丢掉 数据 包 后 返回 


*/discard and undo: /* 丢弃 数据 包 


机 并 tcp clear _ options (&tp->rx opt); tp->rx opt.mss clamp = saved clamp; goto discard;reset and undo: /* 重 置 连 接 。 与 丢弃 数据 包 的 区 别 在 于 返回 值 。 非 


0 时 ， 调 用 者 会 重 置 连接 


tcp clear options(&tp->rx opt); tp->rx opt.mss clamp = saved clamp; return 1;} 


12.5.4 接收 ACK 数 据 包 ， 完 成 三 次 握手 



































在 前 文中 ， 我 们 已 经 知道 了 发 往 本 机 的 TCP 数 据 包 会 进入 tcp_v4_ do rcv。 但 因为 此 时 还 未 真正 地 完成 三 次 握手 ， 所 以 TCP 仍 然 是 未 连接 状态 ， 自 然 就 会 再 次 进入 
函数 tcp_v4_hnd req 了 。 









































static struct sock *tcp v4 hnd req(struct sock *sk, struct sk buff *skb){ struct tcphdr *th = tcp hdr (skb); const struct iphdr *iph = ip hdr (skb); struct sock *nsk; 


SYN 请 求 时 ， 已 经 将 对 应 的 


Lequest_Sock 加 入 到 了 队列 中 ， 因 此 这 次 收 到 


RCK 答 复 时 ， 是 


可 以 找到 对 应 的 


Fequest_Sock 的 - 


另外 需要 注意 的 是 ， 这 个 函数 还 会 有 一 个 输出 值 


Prev， 其 为 返回 值 


req 前 面 的 元 素 。 之 所 以 返回 这 个 


Prev 值 ， 是 为 了 在 后 面 的 


七 cP_check req 函数 中 ,， 移 除 


req 时 ， 不 需要 进行 第 二 次 查找 


*/ struct request sock *req = inet csk search reql(sk, &prev, th->source, iph->saddr, iph->daddr); if (req) retur 


wd 


























下 面 进入 tcp_check req 函 数 : 











struct sock *tcp check req(Struct sock *sk, struct sk buff *skb, struct request sock *req, struct request sock **prev){ struct tcp options receiv 


Saw_tstamp， 因 为 时 间 截 选项 依赖 于 每 个 数据 包 


wf tmp opt.saw tstamp = 0; if (th->doff > (sizeof (struct tcphdr)>>2)) { /* 车 实际 数据 位 置 偏 移 量 大 于 


了 TCP 固定 报头 长 度 ， 则 表明 该 报 文 一 定 包含 了 


了 TCP 选项 

id /* 解析 

了 TCP 选项 

A tcp parse options(skb, &tmp opt, &hash location, 0); /* 判断 是 否 有 时 间 惟 选项 

机 并 if (tmp opt.saw tstamp) { /* 检查 时 间 戴 选项 

二 tmp opt.ts recent = req->ts recent; /* We do not store true stamp, but it is not required, * it can be estimated (approximately) 
SYN 包 为 重 传 的 


SYN 包 , 回复 


SYN+ACK*/ req->rsk ops->rtx syn ack(sk, req, NULL); return NULL; } /* 非法 的 


ACK 值 

A if ((flg & TCP FLAG ACK) && (TCP_SKB CB (skb)->ack seq != tcp rsk(req)->snt isn + 1 + tcp s data sizel(tcp sk(sk)))) return sk; /* 时 间 蕉 检查 失败 ， 或 
本 if (paws reject || !tcp in window(TCP SKB CB (skb)->seq， TCP_ SKB CB (skb)->end seq, tcp rsk(req)->rcv isn + 1, tcp rsk(req)->rcv isn + 1 + req->rcv wnd)) { 
RACK 责 认 

六 if (!(flg & TCP FLAG RST)) req->rsk ops->send ack(sk, skb, req); /* 车 时 间 惟 检测 失败 ， 则 增加 相应 的 计数 

*/ if (paws reject) NET_INC STATS BH(sock net (sk), LINUX MIB PAWSESTABREJECTED); return NULL; } /* In sequence, PAWS is OK. */ /* 车 数据 包 为 有 序数 据 
*/ if (tmp opt.saw tstamp && !after(TCP SKB CB (skb)->seq, tcp rsk(req)->rcv isn + 1)) req->ts_recent = tmp opt.rcv tsval; /* 若 序列 号 在 接收 窗口 之 外 ， 则 去 掉 

SYN 标 志 

bi if (TCP_ SKB CB(skb)->seq == tcp rsk(req)->rcv isn) { /* Truncate SYN, it is out of window starting at tcp rsk(req)->rcv isn + 1. */ Flyg t= ~TCP F 
SYN 和 


RST 标 志 ， 若 都 设置 了 ， 则 将 当前 半 连 接 从 队列 中 清除 


*/ if (flg & (TCP FLAG RSTITCP FLAG SYN)) { TCP_INC STATS BH(sock net (sk), TCP MIB ATTEMPTFAILS); goto embryonic reset; } /* 若 没有 设置 
RCK， 则 丢弃 该 包 
本 if (!(flg & TCP_ FLAG ACK)) return NULL; /* While TCP DEFER ACCEPT is active, drop bare ACK. */ /* 如 果 设置 了 延迟 接收 ， 则 丢弃 单独 的 
RCRK 包 
&/ if (req->retrans < inet csk(sk)->icsk accept queue.rskq defer accept && TCP_SKB CB (skb)->end seq == tcp rsk(req)->rcv isn + 1) { inet rsk(req)->acked = 1; 
SYN+ACK 时 间 
是 if (tmp opt.saw tstamp && tmp opt.rcv tsecr) tcp rsk(req)->snt synack = tmp opt.rcv tsecr; else if (req->retrans) /* don't take RTT sample if retrans && ~TS 


TCP 的 三 次 握手 已 经 完成 。 使 用 


Syn_recv_sOCck 创 建 真正 的 套 接 字 


be child = inet csk(sk)->icsk af ops->syn recv sock(sk, skb, req, NULL); if (child == NULL) goto listen overflow; /* 新 的 套 接 字 已 经 创建 ， 因 此 原来 的 


request sock 可 以 从 队列 中 删除 


eR inet csk reqsk queue unlink (sk, req, prev); inet csk reqsk queue removed (sk, req); /* 将 套 接 字 加 入 到 已 连接 的 队列 中 


bi inet csk reqsk queue add(sk, req, child); return child;listen overflow: if (!sysctl tcp abort on overflow) { inet rsk(req)->acked = 1; return NULL; 






































3 
bi 
党 


一 个 新 创 





这 样 ， 当 tcp_check req 成 功 返 








的 sock 结 构 。 那 么 在 tcp_v4_do_rcv 中 ， 就 会 进入 tcp_child_process 中 。 





int tcp child process(struct sock *parent, struct sock *chilg, struct sk buff *skb){ int ret = 0; int state = child->sk state; /* 检查 


SOCK 是 否 正在 被 用 户 进程 使 用 


bd if (!sock owned by user(child)) { /* 用 户 进程 没有 占用 


SOCk 的 情况 


ff ret = tcp rcv state process(child, skb, tcp hdr (skb)， s 


SOCk 的 任务 


下 if (state == TCP SYN RECV && child->sk _ state != state) 


SOCK， 将 数据 包 加 入 


backlog， 以 后 再 处 理 


*/ _ sk add backlog (child, skb); } 


bh unlock sock(child); 


sock put (child) 7 


kb->len); 


parent->sk data ready (parent, 0); 


/* Wakeup parent, send SIGIO */ 


return ret;} 


/* 唤醒 阻塞 在 父 


else { /* 由 于 用 户 进程 占用 着 














这 里 我 们 考虑 数据 包 被 立刻 处 理 的 情况 ， 即 








户 进程 没有 占 











析 ，tcp_rcv_state_process 是 根据 套 接 字 的 状态 来 处 理 数据 包 的 。 

















sock 的 状态 是 监听 状态 。 那 么 child 的 状态 是 何 时 改变 的 呢 ? 





El 








让 我 们 退 











到 创建 child 的 函数 tcp_v4_syn_recv_sock->tcp_create_openreq_child->inet_csk_clonej 











sock 结 构 ， 那 么 这 里 数据 还 是 会 ; 
而 child 是 从 父 sock 生 成 的 ， 所 以 如 














入 tcp_rcv_state_process 的 。 根 据 前 
果 child 的 状态 和 父 sock 的 状态 一 














的 分 
致 ， 肯 定 是 有 问题 的 























Fh， 代码 如 下 : 





struct sock *inet csk clone(struct sock *sk, const struct request sock *reqg, 


SOCk 结 构 

pf struct sock *newsk = sk clonel(sk, priority); 
SOCk 信 息 

struct inet connection sock *newicsk = inet . 
SOCK 设 置 为 


TCP_SYN_RECV 状 态 


uy newsk->sk_ state = TCP SYN RECV; 


*/ 


return newsk;} 


const gfp t priority){ 


if (newsk != NULL) { /* 开始 克隆 面向 连接 的 


csk (newsk); /* 将 新 


newicsk->icsk bind hash = NULL; 


/* 后 面 是 复制 其 他 变量 的 代码 ， 在 此 省 略 掉 


/* 克隆 一 个 新 的 





这 个 函数 的 命名 稍稍 有 些 别扭 ， 名 字 叫 做 clone〈 克 隆 ) ， 也 就 是 说 ， 所 有 的 内 容 都 应 该 保持 一 致 。 而 这 号 


态 并 不 一 致 。 








下 面 来 查看 tcp_recv_state_process 处 理 TCP_SYN_RECV 状 态 的 代码 : 








有 在 这 个 inek_csk_clone 后 ， 新 sock 的 状态 与 父 sock 的 状 





Case TCP_ SYN RECV: Fd acceptable 是 


tcp_rcv_state_process 在 前 面 对 


RACK 数 据 包 进行 的 判断 - 


A if (acceptable) { /* 这 时 已 经 完成 了 三 次 握手 
A /* 初始 化 用 户 态 未 读数 据 的 序列 号 是 我 们 期 待 接收 的 下 一 个 序列 号 
A tp->copied seq = tp->rcev nxt; smp_mb () 7 
*/ tcp set state (sk, TCP ESTABLISHED); /* 


Sock_def wakeuP， 其 会 唤醒 


Sleep 在 该 


/* 设置 连接 状态 为 已 连接 


Sk_state_change 为 一 个 回调 函数 


， 默认 为 


SOCket 的 进程 


*f sk->sk state change (sk); /* 车 该 


SOCKkK 有 对 应 的 用 户 态 


SOCKket， 则 执行 异步 


工 /O 通 知 


i 这 里 需要 注意 的 是 ， 对 于 我 们 目前 的 情况 来 说 。 子 


SOCK 是 从 监听 


SOCk clone 而 来 的 ,其 中 


sk_sleep 和 


Sk_socket 孝 是 


NULL., 


那么 三 次 握手 以 后 ， 阻 塞 在 监听 


SOCket 的 进程 是 如 何 被 唤醒 的 呢 ? 


tcpP_chi1d Process 在 调用 


tcp_rcv_state process 后 , 会 检查 


SOCk 状 态 是 否 发 生 了 变 


化 。 如 果 发 生 了 变化 ， 则 会 调用 


parent->sk_data _ ready (Parent， 0) ;这 样 ， 就 可 以 将 事 


件 通知 到 阻塞 在 监听 
SOCk 的 进程 了 。 
wy if (sk->sk socket) sk wake async (sk, SOCK_WAKE IO, POLL OUT); /* 初始 化 未 确认 回复 的 序列 号 
本 tp->snd una = TCP SKB CB (skb) ->ack_ seq; /* 初始 化 发 送 窗口 
bi tp->snd wnd = ntohs (th->window) << tp->rx opt.snd wscale; tcp init wl (tp, TCP SKB CB(skb)->seq); /* 如 果 有 时 间 惟 选项 ， 则 


MSS 需 要 减 去 时 间 戴 所 占 的 大 小 




















wy if (tp->rx opt.tstamp ok) tp->advmss -= TCPOLEN TSTAMP ALIGNED; /* Make sure socket is routed, for * correct metrics. $y i 
tcp init metrics (sk); tcp init congestion control (sk) /* Prevent spurious tcp cwnd restart() on * first data packet. Sy tp->lsnd 
目前 为 止 ， 三 次 握手 的 源码 分 析 已 经 结束 了 。 其 内 部 还 有 很 多 细节 值得 展开 学 习 ， 但 那 就 不 是 一 两 个 章节 所 能 完成 的 任务 了 。 笔 者 只 是 抛 砖 引 出 一 个 及 









































内 
络 ， 关 于 剩 下 的 细节 大 家 可 以 自己 通过 阅读 代码 来 完善 。 





第 13 章 ”网 络 通信 : 数据 报 文 的 发 送 





第 12 章 学 习 了 Linux 套 接 字 的 创建 、 监 听 和 连接 ， 并 重点 分 析 了 TCP 建 立 连 接 时 的 三 次 握手 过 程 。 
本 章 将 从 应 用 层 到 内 核 来 研究 数据 包 的 发 送 过 程 。 





13.1 发送 相关 接口 











Linux 内 核 为 套 接 字 提供 了 多 个 发 送 数据 的 接口 ， 接 口 定 义 如 下 : 








#include <sys/types.h> 
#include <sys/socket.h> 
ssize t sendl(int sockfd, const 
ssize t sendtol(lint sockfd, con 


void *buf, size t len, int flags); 
st void *buf, size t len, int flags, 


const struct sockaddr *dest addr, socklen t addrlen); 
ssize t sendmsg(int sockfd, const struct msghdr *msg, int flags); 








send 只 能 用 于 处 理 已 连接 状态 的 套 接 字 〈 注 意 ， 从 第 11 章 的 内 容 已 经 知道 ， 无 论 是 UDP 还 是 TCP， 
都 可 以 进行 连接 ) 。 而 sendto 可 以 在 调用 时 ， 指 定 目的 地 址 。 这 样 的 话 ， 如 果 套 接 字 已 经 是 连接 状态 ， 
那么 目的 地 址 dest addr 与 地 址 长 度 就 应 该 为 NULL 和 0， 不 然 就 可 能 会 返回 错误 。sendmsg 则 比较 特殊 ， 
无 论 是 要 发 送 的 数据 还 是 目的 地 址 ， 都 保存 在 msg 中 。 其 中 msgmsg_name 和 msgmsg_ len 用 于 指明 目的 地 
址 ， 而 msgmsg iov 则 用 于 保存 要 发 送 的 数据 。 这 三 个 系统 调用 都 支持 设置 指示 标志 位 flags。 




















说 明 ”稍微 现代 些 的 系统 调用 ， 一 般 都 会 拥有 或 保留 一 个 指示 标志 参数 。 通 过 标志 位 





flags， 可 以 从 容 地 为 系统 调用 





兽 加 新 功能 ， 并 同时 兼容 老 版 本 。 第 1 章 中 介绍 的 dup、dup2 和 dup3 则 是 这 








方面 的 一 个 反面 典型 。 在 不 支持 flag 的 情况 下 ， 不 得 不 一 再 创建 新 的 dup 接 口 ， 直 到 dup3 加 入 了 对 flag 的 


支持 为 止 。 








由 于 socket 同 时 还 是 文件 描述 符 ， 所 以 为 文件 提供 的 写 操作 (如 write、writev 等 ) ， 也 可 以 被 socket 
套 接 字 直 接 调 用 ， 在 此 就 不 重复 叙述 了 。 





13.2 ”数据 包 从 用 户 空间 到 内 核 空间 的 流程 


从 13.1 节 可 知 ，socket 套 接 字 在 发 送 数据 包 时 有 多 个 系统 调用 ， 既 有 套 接 字 本 身 的 发 送 接口 ， 又 可 
以 重用 文件 描述 符 的 写 操作 。 这 些 不 同 的 接口 是 否 会 导致 数据 包 从 用 户 空 间 发 送 到 内 核 空 间 时 走向 不 
同 的 流程 呢 ? 下 面 让 我 们 通过 阅读 源码 来 回答 这 个 问题 。 








send 的 内 核实 现代 码 如 下 : 








SYSCALL DEFINE4 (send, int, fd, void user *, buff, size t, len, 
unsigned, flags) 
( 


/* 
Seng 可 以 视 为 


Sendto 的 一 种 特例 ， 即 不 设置 目的 地 址 的 








Sendto 调 用 。 











所 以 内 核实 现 也 是 让 











Send 直 接 调 








sendto., 


*/ 
return sys_ sendtol(fd, buff, len, flags, NULL, 0); 
| 





既然 其 内 核实 现 是 让 send 直 接 调用 sendto， 那 么 ， 下 面 我 们 就 来 看 一 下 sendto 的 内 核实 现 ， 代 码 如 





SYSCALL DEFINE6 (sendto, int, fd, void user *, buff, size t, len, 
unsigned, flags, struct sockaddr user *, addr, 
int, addr len) 
{ 
struct socket *sock; 
struct sockaddr storage address; 
int err; 上 
struct msghdr msg; 
struct iovec iov; 
int fput needed; 
/* 长 度 合法 性 检查 





WA 
if (len > INT MAX) 


len = INT MAX; 
/* 从 文件 描述 符 获 得 套 接 字 





SOCKkKet 的 结构 


sock = sockfd lookup light (fd, &err, &fput needed); 


if (!sock) 
Ooie: OU 


/* 将 数据 转换 为 




















iovec 结 构 ， 来 调用 后 面 的 

sendmsg */ 
iov.iov base = puff; 
iov.iov len = len; 
msg.msg name = NULL; 
msg.msg iov = &iov; 
msg.msg iovlen = 1; 
msg.msg control = NULL; 
msg.msg controllen = 0; 
msg.msg namelen = 0; 


/* 如 果 设置 了 地 址 ， 则 设置 


msg name */if (aqqr) { 


*/ 


下 
立 在 


/* 将 地 址 参数 复制 到 内 核 变量 中 





move addr to _ kernel (addr, addr len, 
(err < 0) 


goto out put; 


msg.msg name = 
msg.msg namelen 


} 
/* 如 果 


addr len; 


SOCket 设 置 了 非 阻 塞 ， 则 消息 的 标志 设置 为 





DONTWAIT (其 实 也 是 非 阻塞 的 语义 ) 


*/ 


if (sock->file->f flags & O NONBLOCK) 


msg.msg flags 
/* 调 

















flags |= MSG DONTWAIT; 


flags; 


SOCk_sendmsg 来 发 送 数 据 包 


«7 


err 
Out Put 


sock sendmsg(sock, é&msg, len); 


fput light (sock->file, fput needed); 


Gut: 
return err; 
} 


(struct sockaddr *) &address; 


(struct sockaddr *) &address); 





这 里 又 调用 到 sock sendmsg 了， 从 名 字 上 


、 





面 让 我 们 来 验证 这 个 猜想 。 





也 


会 


被 第 三 个 接口 sendmsg 所 调用 。 下 








SYSCALL DEFINE3 (sendmsg, int, fd, struct msghdr user * msg unsigned, flags) 
{ 

int fput needed, err; 

struct msghdr msg sys; 

/* 通过 文件 描述 符 获 得 


SOCKet 套 接 字 结构 


类 

& 
struct socket *sock = sockfd lookup light (fd, &err, &fput needed); 
if (!sock) 

ookES: .Ou 

/* 调 

















__SySs_senqdmsg 来 发 送 数 据 包 


大 

/ 
err = Sys sendmsg(sock, msg, é&msg sys, flags, NULL); 
fput light (sock->file, fput needed); 

out: 
return err; 

} 





接 下 来 进入 _sys_sendmsg， 代 码 如 下 : 





static int sys sendmsg(struct socket *sock, struct msghdr _user *msg, 
struct msghdr *msg sys, unsigned flags, 
struct used address *used address) 





struct compat msghdr _user *msg compat = 

(struct compat msghdr user *)msg; 
struct sockaddr storage address; 
struct iovec iovstack[UIO FASTIOV], *iov = iovstack; 
unsigned char ctl[sizeof (struct cmsghdr) + 20] 

attripbute ((aligned(sizeof( kernel size t+)))); 

/* 20 is size of ipv6 pktinfo */ 
unsigned char *otl buf = ctl} 
int err, ctl len, iov size, total len; 
err = -EFAULT; 
/* 从 用 户 空间 得 到 用 户 消息 
































4 
if (MSG CMSG COMPAT & flags) { 
/* 紧凑 消息 类 型 


大 
if (get compat msghdr (msg sys, msg compat)) 
return -EFAULT; - 
} else if (copy from user (msg sys, msg, sizeof (struct msghdr))) 
return -EFAULT; 加 
/* do not move before msg sys is Valid */ 
err = -EMSGSIZE; 加 
/* 消息 数据 块 个 数 检查 























大 
/ 
if (msg_ sys->msg iovilen > UIO MAXIOV) 
goto out; 
/* Check whether to allocate the iovec area */ 
err = -ENOMEM; 











/* 在 内 核 空间 申请 消息 数据 长 度 





3 
iov size = msg sys->msg iovlen * sizeof(struct iovec); 
if (msg sys->msg iovlen > UIO FASTIOV) { 


iov = Sock kmalloc(sock->sk, iov size, GFP KERNEL); 
YE (VO) 
goto out; 


} 


/* This will also move the address data into kernel space */ 
/* 前 面 只 是 将 消息 头 ， 或 者 说 消息 的 结构 体 ， 复 制 到 内 核 空间 ， 现 在 是 将 消息 的 真正 内 容 ， 即 





iOV 的 内 容 复制 到 内 核 空 间 


大 
/ 
if (MSG CMSG COMPAT & flags) { 
err = verify compat iovec (msg_ sys, iov, 
(struct sockaddr *) &address, 
ERIFY READ); 











} else 
err = verify iovec (msg sys, iov, 

(struct sockaddr *) &address, 

ERIFY READ); 














if (err < 0) 
goto out freeiov; 
total len = err;err = -ENOBUFS;/* 与 消息 数据 块 类 似 ,复制 控制 消息 块 ， 就 不 详细 描述 了 





大 
/ 
if (msg_ sys->msg controllen > INT MAX) 
goto out freeiov; 
cti1 len = msg sys->msg controllen; 
if ((MSG CMSG COMPAT & flags) && ctl] len) { 
SE 
cmsghdr from user compat to kern(msg sys, sock->sk, ctl, 
sizeof (ct1)); 





if (err) 
goto out freeiov; 
cti1 buf = msg sys->msg control; 
cti1 len = msg sys->msg controllen; 
} else if (ctl len) { 
if (ctl len > sizeof (ct1)) { 
ctl buf = sock kmalloc(sock->sk, ctl len, GFP KERNEL); 
if (ct1 buf == NULL) 下 
goto out freeiov; 
} 
err = -EFAULT; 
/* 
* Careful! Before this, msg sys->msg control contains a user pointer. 
* Afterwards, it will be a kernel pointer. Thus the compiler-assisted 
* Checking falls down on this. 
大 
/ 
if (copy from user(ctl buf， 
(void user _ force *)msg sys->msg control, 
ctl len)) 
goto out freectl; 
msg_sys->msg_control = ctl buf;}/* 设置 消息 标志 





4 
msg_sys->msg flags = flags; 
/* 如 果 套 接 字 是 非 阻塞 的 ， 则 设置 消息 标志 


MSG DONTWAIT */ 
~ if (sock->file->f flags & O NONBLOCK) 
msg_sys->msg flags |= MSG DONTWAIT; 
/* 如 果 这 次 发 送 的 目的 地 址 与 上 次 成 功 发 送 的 目的 地 址 一 致 ， 那 就 可 以 省 略 安全 性 检查 


守 
/ 
if (used address && msg sys->msg name && 
used address->name len == msg sys->msg namelen && 
!memcmp (&used address->name, msg _ sys->msg name, 
used address->name len)) { 
/* 调用 不 进行 安全 性 检查 的 函数 


err = Sock sendmsg nosec(sock, msg sys, total len); 
goto out freectl; 


/* 调用 

















SOCk_sendmsg， 需 要 安全 性 检查 ， 最 终 仍然 会 调用 到 


SOCk_send msg_nosec 函 数 


要/ 
err = Sock sendmsg(sock, msg sys, total len); 
/* 如 果 本 次 发 送 成 功 ， 则 保存 当前 的 目的 地 址 


大 
/ 
if (used address && err >= 0) { 
used address->name len = msg sys->msg namelen; 
if (msg sys->msg name) 
memcpy (&used address->name, msg sys->msg name, 
used address->name len); 











} 
out freectl: 
Ef (Ctl .buf J= EL) 
sock kfree s(sock->sk, ct buf, ct len); 
out freeiov: 
if (iov != iovstack) 
sock kfree s(sock->sk, iov, iov size); 
out: 
return err; 
} 








看 完了 _ sys_sendmsg， 我 们 可 以 确定 ， 无 论 是 哪个 发 送 数据 的 系统 调用 ， 最 终 都 会 调用 到 
sock sendmsg。 下 面 是 sock sendmsg 的 相关 代码 : 








int sock _ sendmsg (Struct socket *sock, struct msghdr *msg Size 七 Size) 














/* Kiocb 为 内 核 通 用 的 








工 O 请 求 结 构 


大 

/ 
struct kiocb iocb; 
struct sock iocb siocb; 
int ret; 
/* 初始 化 同步 的 内 核 


工 O 请 求 结构 


5 
init sync kiocb(&iocb, NULL); 
iocb.private = &siocb; 
/* 发 送 消息 


*/ 
ret = sock sendmsg(&iocb, sock, msg, size); 
/* 返回 结果 表明 该 消息 已 经 加 入 队列 ， 要 等 待 完成 事件 


4 
if (-EIOCBQUEUED == ret) 
ret = wait on Sync kiocb(&iocb); 


Veturn ety 





这 里 _sock_ sendmsg 只 是 做 了 安全 性 检查 ， 然 后 就 调用 了 __sock_sendmsg_nosec 函 数 。 再 继续 看 
_ Sock sendmsg nosec， 代 码 如 下 : 





static inline int sock sendmsg nosec (Struct kiocb *iocb, struct socket *sock, 
struct msghdr *msg, size t size) 





/* 获得 套 接 字 在 





Sock_senqdmsg 中 设置 的 


IO 请 求 ， 


*/ 
struct sock iocb *si = kiocb to siocb (iocb); 
sock update classid(sock->sk); 
/* 初始 化 套 接 字 的 


工 O 请 求 字段 

tp 
Si->sock = sock; 
si->scm = NULL; 
Si->msg = msg; 


si->size = size; 
/* 根据 不 同 的 套 接 字 类 型 ， 调 用 其 发 送 数据 函数 























4 
return sock->ops->sendmsg (iocb, sock, msg, size); 





到 此 ， 我 们 完成 了 数据 包 从 用 户 空间 到 内 核 空间 的 流程 跟踪 。 接 下 来 的 数据 包 发送 过 程 ， 将 根据 
不 同 的 协议 ， 走 不 同 的 流程 。 





13.3 UDP 数据 包 的 发 送 流程 
































已 经 跟踪 了 数据 包 从 用 户 空间 到 内 核 空 间 的 流程 ， 本 节 将 以 比较 简单 的 UDP 协议 为 例 ， 继 续 跟踪 数据 包 的 发 送 流程 一 一 因 











前 文 
以 不 会 给 我 们 的 代码 分 析 带 来 额外 的 麻烦 。 





UDP 的 sendmsg 操 作 函 数 为 udp_sendmsg， 代 码 如 下 : 


为 UDP 是 无 连接 状态 的 协议 ， 所 








int udp sendmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg, size t len) 


/xs 从 


inet 通 用 套 接 字 得 到 


inet 套 接 字 


二 
struct inet sock *inet = inet sk(sk); 
ss 从 


inet 通 用 套 接 字 得 到 


UDP 套 接 字 


.A 
struct udp sock *up = udp sk(sk); 
struct flowi4 f14 stack; 
struct flowi4 *f147 
int ulen = len; 
struct ipcm cookie ipc; 
struct rtable *rt = NULL; 
int free 一 07 
int connected = 0; 
_ be32 daddr, faddr, saddr; 
_ be16 dport; 
u8 tos; 
int err, is udplite = IS UDPLITE (sk); 
/* 是 否 有 数据 包 聚 合 : 或 者 


UDP 套 接 字 设置 了 聚合 选项 ， 或 者 数据 包 浮 





息 指明 了 还 有 更 多 数据 


wh 
int corkreq = up->corkflag || msg->msg flagsg&MSG MORE; 
int (*getfrag) (void *, char *, int, int, int, struct sk buff *); 
struct sk buff *skb; 
struct ip options data opt copy; 
/* 数据 包 长 度 检查 


Bd 
if (len > OxFFFF) 
return -EMSGSIZE; 
/* 检查 消息 标志 





志 ， 


UDP 不 支持 带 外 数据 


四 
/ 
if (msg->msg flags & MSG OOB) /* Mirror BSD error message compatibility */ 
return -EOPNOTSUPP; 
ipc.opt = NULL; 
ipc.tx flags = 0; 
/* 设置 正确 的 分 片 函数 


四 
/ 
getfrag = is udplite ? udplite getfrag : ip generic getfrag; 
f14 = &inet->cork.fl.u.ip4; 
if (up->pending) { 
/* 该 


UDP 套 接 字 还 有 待 发 的 数据 包 


可 
lock sock(sk); 
/* ”常见 的 上 锁 双 重 检查 机 制 


过 
if (likely(up->pending)) { 
/* 车 待 发 的 数据 不 是 


INET 数 据 ， 则 报错 返回 


wf 
if (unlikely (up->pending != AF INET)) { 
release sock (sk); 
return -EINVAL; 
} 
/* 调 到 追加 数据 处 


Wd 
goto do append data; 

} 

release sock (sk); 
} 
ulen += sizeof (struct udphdr); 
if (msg->msg name) { 

/* 车 指定 了 目标 地 址 ， 则 对 其 进行 校 验 


ef 
struct sockaddr in * usin = (struct sockaddr in *)msg->msg name; 
/* 检查 长 度 
wy 
if (msg->msg namelen < sizeof(*usin)) 
return -EINVAL; 
/* 检查 协议 族 。 目前 只 支持 
AF_INET 和 


AF_UNSPEC 协 议 族 


yy 





if (usin->sin family AF INET) { 
if (usin->sin family != AF UNSPEC) 
return -EAFNOSUPPORT; 


} 
/* 车 通过 了 检查 ， 则 设置 目的 地 址 与 目的 端口 


*/ 
daddr = usin->sin addr.s addr; 
dport = usin->sin port; 
/* 目的 端口 不 能 为 


WS 
if (dport == 0) 
return -EINVAL; 
else { 


/* 如 果 没有 指定 目的 地 址 和 目的 端口 ， 则 当前 套 接 字 的 状态 必须 是 已 连接 ， 即 已 经 调用 过 





Connect 设 置 了 目的 地 址 


* 
if (sk->sk state != TCP ESTABLISHED) 
return -EDESTADDRREQ; 
/* 使 用 之 前 设置 的 目的 地 址 和 目的 端口 
wf 





daddr = inet->inet daddr; 
dport = inet->inet dport; 
/* Open fast path for connected socket. 
Route will not be used, if at least one option is set. 
Wd 
connected = 1; 
} 
ipc.addr = inet->inet saddr; 
ipc.oif = sk->sk bound dev if; 
/* 设置 时 间 截 标志 


yf 
err = sock tx timestamp (Sk，&ipc.tx flags); 
if (err) 
return err: 
/* 发 送 的 消息 包含 控制 数据 


*/ 
if (msg->msg controllen) { 
/* 虽然 这 个 函数 的 名 字 叫 作 


Send， 其 实 并 没有 任何 发 送 动作 ， 而 只 是 将 控制 消息 设置 到 


ipc 中 
yy 
err = ip cmsg send(sock net (sk), msg, &ipc); 
if (err) 
return err; 
/* 设置 释放 


ipC .Opt 的 标志 


i 
if (ipc.opt) 
Eree = 17 
connected = 0; 
. 
if (lipc.opt) 1{ 
/* 如 果 没 有 使 用 控制 消息 指定 


工 P 选 项 ， 则 检查 套 接 字 的 


工 P 选 项 设置 。 如 果 有 ， 则 使 用 套 接 字 的 


工 P 选 项 


bd 
struct ip options rcu *inet opt; 
rcu read lock(); 
inet opt = rcu dereference (inet->inet opt); 
if (inet opt) 工 
memcpy (&opt_ copy, inet opt, 
sizeof (*inet opt) + inet opt->opt.optlen); 
ipc.opt = &opt copy.opt; 
} 
rcu read unlock(); 
; 
saddr = ipc.addr; 
ipc.addr = faddr = daddr; 
/* 设置 了 严格 路 由 


*/ 

if (ipc.opt && ipc.opt->opt.srr) { 

if (!daddr) 
return -EINVAL; 

faddr = ipc.opt->opt.faddr; 
connected = 0; 

} 

tos = RT TOS (inet->tos); 

/* 

车 有 下 列 情况 之 一 的 : 


1) 套 接 字 设置 了 本 地 路 由 标志 。 


2) 发 送 消息 时 ， 指 明了 不 做 路 由 。 


3) 设置 了 


工 P 严 格 路 由 选项 。 


则 设置 不 查找 路 由 标志 


六 
/ 
if (sock flag(sk, SOCK LOCALROUTE) || 
(msg->msg flags & MSG DONTROUTE) || 
(ipc.opt && ipc.opt->opt.is strictroute)) { 
tos |= RTO ONLINK; 
connected = 0; 
. 
/* 如 果 目 的 地 址 是 多 播 地 址 


家 
if (ipv4 is multicast (daddr)) { 
/* 车 未 指定 出 口 接口 ， 则 使 用 套 接 字 的 多 播 接口 索引 


sp 
if (lipec.oif} 
ipc.oif = inet->mc index; 
/* 车 源 地 址 为 


0， 则 使 用 套 接 字 的 多 播 地 址 


本 
if (!saddr) 
saddr = inet->mc addr; 
connected = 0; 
’ 
/* 连接 标志 为 真 ， 即 此 次 发 送 的 数据 包 与 上 次 的 地 址 相同 ， 则 判断 保存 的 路 由 缓存 是 否 还 可 用 。 
# 


if (connected) { 
/* 从 套 接 字 检查 并 获得 保存 的 路 由 缓存 


本 
rt = (struct rtable *)sk dst check(sk, 0); 


上 
/* 车 目前 路 由 组 





则 需要 查找 路 由 


4 
if (rt == NULL) { 
struct net *net = sock net (sk); 
£14 = &f14 stack; 
/* 根据 套 接 字 和 数据 包 的 信息 ， 初 始 化 


£1 Owi 4- 这 是 查找 路 由 的 


key */ 
flowi4 init output (f14, ipc.oif, sk->sk mark, tos, 
RT_SCOPE UNIVERSE, sk->sk protocol, 
inet sk flowi flags (sk) |FLOWI FLAG CAN SLEEP, 
faddr, saddr, dport, inet->inet sport); 


security sk classify flow(sk，flowi4 to flowi(f14) ) 7 
/* 查找 出 口 路 由 





A 
rt = ip route output flow(net, fl14, sk); 
if (IS ERR(rt)) { 
/* 查找 路 由 失败 
.A 
if (err -ENETUNRERACH) 
IP_INC STATS BH(net, IPSTATS MIB OUTNOROUTES); 
goto out; 
} 
err = -EACCES; 
/* 车 路 由 是 广播 路 由 ， 并 且 套 接 字 非 广播 套 接 字 
*/ 


if ((rt->rt flags & RTCF BROADCAST) && 
!sock flag(sk, SOCK BROADCAST)) 
goto out; 

if (connected) { 
/* 车 该 


UDP 为 已 连接 状态 ， 则 保存 这 个 路 由 缓存 


二 
sk qdst_set (Sk，dst_clone (&rt->QSst) ) 7 
} 


上 
/* 如 果 数 据 包 设置 了 
MSG_CONFIRM 标 志 ， 则 是 要 告诉 链 路 层 ， 对 端 是 可 达 的 。 调 到 


do_confrim 处 , 可 


以 发 现 其 实现 方法 是 在 有 





neibour 确 认 时 间 战 为 当前 时 间 。 


*/ 
if (msg->msg flagsg&MSG CONFIRM) 
goto do confirm; 
back from confirm: 
saddr = £14->saddr; 
if (!ipc.addr) 
dagdr = ipc.addr = f14->daddr; 
/* 没有 使 用 


COrk 选 项 或 


MSG_MORE 标 志 。 这 也 是 最 常见 的 情况 。 


WA 
if (!corkreq) { 
/* 每 次 都 生成 一 个 


UDP 数据 包 


4 
Skb = ip make skb(sk, f14, getfrag, msg->msg iov, ulen, 
sizeof (struct udphdr), g&ipc, &rt, 
msg->msg flags); 
err = PTR ERR(skb); 
/* 成 功 生成 了 数据 包 


过 
if (skb && !IS ERR(skb)) { 
/* 发 送 
UDP 数据 包 
a 


err = udp send skb(skb, £14); 
; 
goto out; 


} 

lock sock (sk); 

if (unlikely (up->pending)) { 
/* 
现在 马上 要 做 


COrk 处 理 ， 但 发 现 套 接 字 已 经 


CorkT. 


因此 这 是 一 个 应 用 程序 


bug. 释放 套 接 字 锁 ， 并 返回 错误 。 


we 
release sock (sk); 
LIMIT NETDEBUG (KERN DEBUG "udp cork app bug 2\n"); 


err = -EINVAL; 
goto out; 
上 
/* 
Now cork the socket to pend data. 
SE 
/* 设置 





4 


£14 = ginet->cork.fl.u.ip4; 
£14->daddr = daddr; 
£14->saddr = saddr; 


£14->f14 dport = 


dport; 


£14->f14 sport = inet->inet sport; 
up->pending = AF _ INET; 

do append data: 

/* 增加 


UDP 数据 长 度 


*/ 


up->len += ulen; 


/* 


向 


工 P 数 据 包 中 追加 新 的 数据 


err 


if 


else if (!corkreq) 


= ip append data(sk，f14，getfrag，msg->msg iov, ulen, 
sizeof (struct udphdr), &ipc, &rt, 
corkreq ? msg->msg flags|MSG MORE : 


(err) // 车 发 生 错误 ， 则 丢弃 所 有 未 决 的 数据 包 


udp flush pending frames (sk); 
// 车 不 在 


Cork 即 阻塞 ， 则 发 送 所 有 未 决 的 数据 包 


out: 


M4 


*/ 


err = udp push pending frames (sk); 


else if (unlikely (skb queue empty (&sk->sk write queue))) { 


} 


/* 车 没有 未 决 的 数据 包 ， 则 重 置 未 决 标志 


up->pending = 0; 


release sock (sk); 


/* 


清理 工作 ， 释 放 各 种 资源 





统计 计数 


ip rt put(rt); 


if 
if 


上 
ret 


msg->msg flags); 


Reporting 
otherwise 
be too many 
now that 


(free) 

kfree (ipc.opt); 

(!err) 

return len; 

ENOBUFS = no kernel mem, SOCK NOSPACE = no sndbuf space. 

ENOBUFS might not be good (it's not tunable per se), but 

we don't have a good statistic (IpOutDiscards but it can 

things). We could add another new stat but at least for 

seems like overkill. 

(err == -ENOBUFS || test bit(SOCK NOSPACE, &sk->sk socket->flags)) { 





UDP_INC STATS USER(sock net (sk), 
UDP MIB SNDBUFERRORS, is udplite); 


urn err; 


do _ confirm: 


dst 
if 


err 
got 


.Confirm(&rt->dst); 

(! (msg->msg_ flagsg&MSG PROBE) 
goto back from confirm; 

= 0; 

O out; 


len) 





一 般 情况 下 ， 在 使 






































UDP 发 送 数据 包 时 很 少 会 使 用 CORK 或 MSG_MORE 标 志 ， 











为 我 们 希望 在 每 次 调 























必 送 接口 时 ， 就 发 送 一 次 UDP 数据 包 。 





可 











此 可 以 不 必 考 虑 CORK 和 MSG_MORE 的 情况 ， 而 继续 追踪 udp_ 





static int udp send skb (struct sk buff *skb, struct flowi4 *f14) 


{ 


str 
str 
str 
int 
int 
int 
int 


uct sock *sk = skb->sk; 

uct inet sock *inet = inet sk(sk); 
uct udphdr *uh; 

err = 0; 

is udplite = IS_UDPLITE (sk); 

offset = skb transport offset (skb); 
len = skb->len - offset; 


wsum csum = 0; 
/* 创建 


UDP 报 文 头 部 


sy 
uh = udp har (skb); 
uh->source = inet->inet sport; 
uh->dest = f14->f14 dport; 
uh->len = htons (len); 
uh->check = 0; 
/* 如 果 是 轻 量 级 


UDP 协议 ， 则 调用 相应 的 校 验 和 计算 函数 。 


想 了 解 什么 是 


UDP Lite, 请 自行 


wiki. 


才 交 
if (is udplite) 

csum = udplite csum(skb); 
* 禁止 了 


UDP 校 验 和 


else if (sk->sk no check == UDP CSUM NOXMIT) { 
skb->ip_summed = CHECKSUM NONE; 
goto send; 

} else if (skb->ip summed == CHECKSUM PARTIAL) { 
/* 硬件 支持 校 验 和 的 计算 


4 
udp4 hwcsum(skb, f14->saddr, f14->daddr); 
goto send; 
F else 1{ 
/* 一 般 情况 下 的 校 验 和 计算 
wy 
csum = udp csum(skb); 
} 
/* 计算 


UDP 的 校 验 和 ， 需 要 考虑 伪 首 部 


id 
uh->check = csum tcpudp magic(f14->saddr, f14->daddr, len, 
Sk->sk protocol, csum); 
/* 如 果 校 验 和 为 


0， 则 需要 将 其 设置 为 


0xFFFF。 因为 


UDP 的 零 校 验 和 ， 有 特殊 的 含义 ， 表 示 没 有 校 验 和 。 


# 
if (uh->check == 0) 
uh->check = CSUM MANGLED 0; 
send: 
/* 发 送 


工 P 数 据 包 


A 
err = ip send skb(skb); 
if (err) { 
if (err == -ENOBUFS && !inet->recverr) 1{ 
UDP_INC STATS USER(sock net (sk), 
UDP MIB SNDBUFERRORS, is udplite); 
err = 0; 
} 
} else 
UDP_INC STATS USER(sock net (sk), 
UDP MIB OUTDATAGRAMS, is udplite); 
return err; 








至 此 ，UDP 已 经 完成 了 自己 的 工作 ， 后 面 的 发 送 工 作 将 交 由 IP 层 来 负责 。 


















































在 没有 阅读 内 核 源 码 时 ， 我 相信 绝 大 多 数 的 读者 都 会 认为 在 使 用 DDP 套 接 字 时 ， 每 一 次 调用 sendq 都 会 产生 





个 UDP 报 文 。 




















实 上 ， 在 一 般 的 项 目 中 ，UDP 套 接 字 确 实 也 是 这 样 使 

















的 。 然 而 通过 阅读 源码 ， 手 


13.4 TCP 数据 包 的 发 送 流 程 








13.3 节 追踪 了 UDP 数 据 包 的 发 送 流程 ， 本 节 要 学 习 另 外 


TCP 的 sendmsg 操 作 函 数 为 tcp_sendmsg， 代 码 如 下 : 


儿 








要 的 传输 





层 协议 ，TCP 数 据 包 的 发 送 流程 。 





int tcp sendmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg, size t size) 


{ 
struct iovec *iov; 
struct tcp sock *tp = tcp sk(sk); 
struct sk buff *skb; 
int iovlen, flags; 
int mss now, size goal; 
int sg, err, copied; 
long timeo; 
lock sock(sk); 
flags = msg->m: 
/* 根据 标志 ， 确 定 发 送 六 


flags; 
:的 超时 时 间 : 






如 果 设 置 了 


MSG_DONTWAIT， 则 超时 时 间 为 


若 没 有 设置 


MSG_DONTWAIT， 则 使 用 套 接 字 的 超时 时 间 


timeo = sock sndtimeo(sk, flags & MSG DONTWAIT); 
/* 
套 接 字 只 有 处 于 已 连接 ( 


ESTABLISHED) 和 等 待 关闭 ( 





， 才 能 直接 发 送 数据 - 


已 连接 状态 不 用 多 说 。 等 待 关闭 状态 是 指 收 到 对 端 关闭 


(FIN) 数据 包 ， 但 本 端 应 用 还 没有 关闭 连接 时 ， 这 


时 仍然 可 以 发 送 数 据 。 


在 


TCP 协 议 中 ， 发 送 


了 IN， 表 示 本 端 不 会 再 发 送 数据 - 


站 


if ((1 << sk->sk state) & ~(TCPF ESTABLISHED | TCPF CLOSE WAIT)) 


/* 等 待 连接 建立 。 若 失败 则 返回 出 错 





SR 
if ((err = sk stream wait connect(sk, &timeo)) != 0) 
goto out err; 
/* 清除 


SOCK_ASYNC_NOSPACE 标 志 


A 





MSS 长 度 和 数据 包 的 最 大 长 度 


sy 
mss now = tcp send mss(sk, &size goal, flags); 
/* 淮 备 开始 发 送 ， 获 得 用 户 的 数据 向 量 地 址 及 长 度 





四 
/ 
iovlen = msg->msg iovlen; 
iov = msg->msg iov; 
copied gk 
Orr = ~EPIFE} 
/* 错误 检查 





*/if (sk->sk err || (sk->sk shutdown & SEND SHUTDOWN)) 
goto out err; 
/* 判断 出 口 路 由 是 否 支持 分 散 聚 合 功能 


sy 
Sg = sk->sk route caps & NETIF F SG; 
/* 过 个 发 送 数据 自 


* 
while (--iovlen >= 0) { 
/* 得 到 该 数据 段 的 长 度 及 起 始 地 址 


a 
size t seglen = iov->iov len; 
unsigned char _user *from = iov->iov base; 
iov+t+; 


/* 循环 以 保证 本 数据 段 的 数据 全 部 被 发 送 





来 
while (seglen > 0) { 
int copy = 0; 
/* 获得 数据 包 的 最 大 长 度 


wf 





= size goal; 
送 队 列 尾部 的 





Sklb， 查 看 是 否 还 有 剩余 空间 


# 
Skb = tcp write queue tail (sk); 
if (tcp send head(sk)) { 
if (skb->ip summed == CHECKSUM NONE) 
max = mss_now; 
/* 得 到 本 次 需要 复制 的 长 度 
* 


Copy = max - skb->len; 
, 
/* 本 


Skb 的 数据 长 度 已 经 超过 了 最 大 长 度 ， 需 要 申请 新 的 





Skb */ 
if (copy <= 0) { 
new_ segment: 
/* 检查 发 送 缓冲 是 否 已 经 超出 了 限制 
if (!sk stream memory free (Sk)) { 
/* 发送 缓冲 占用 内 存 过 多 ， 需 要 等 竺 
人 
goto wait for sndbuf; 
} 
/* 申请 新 的 
skb */ 
skb = sk stream alloc skbl(sk, 
select size(sk, sg), 
sk->sk allocation); 
if (!skb) { 
/* 若 分 配 失败 ， 则 需要 等 待 
goto wait for memory; 
} 
/* 检查 硬件 是 否 支持 校 验 和 
$A 
if (sk->sk route caps & NETIF F ALL CSUM) 
Skb->ip summed = CHECKSUM PARTIAL; 
/* 加 入 套 接 字 的 发 送 队 列 
wf 
Skb entail (sk, skb); 
copy = size goal; 
max = size goal; 
} 
/* 复制 长 度 不 能 超过 数据 长 度 
wf 


if (copy > seglen) 
copy = seglen; 
/* 判断 


SKb 的 线性 空间 是 否 还 有 空间 


ed 
if (skb availroom(skb) > 0) 
/* 调整 复制 长 度 ， 不 能 超过 空闲 的 空间 长 度 


本 


copy = min t(int, copy, skb availroom(skb)); 


/* 将 数据 复制 到 


Skb 的 空闲 空 间 中 


err = skb add data nocache(sk, skb, from, copy); 


if (err) 
goto do fault; 
} else 1 
/* 如 果 该 


Skb 没 有 足够 的 空闲 的 线性 空间 ， 则 把 数据 复制 到 分 散 聚 合 页 中 





11 !sg) { 


/* 已 经 达到 分 片上 限 ， 或 者 网 络 设备 不 支持 分 散 聚 合 。 这 时 不 能 再 向 分 片 增加 任 


int merge = 0; 
/* 获得 数据 的 分 片 个 数 
wf 
int i = skb shinfo(skb)->nr frags; 
/* 获得 套 接 字 使 用 的 页 
.A 
struct page *page = TCP PAGE (sk); 
/* 获得 该 页 已 使 用 的 偏 移 
int off = TCP OFF (sk); 
/* 判断 数据 包 是 否 可 以 和 最 后 一 个 分 片 聚 合 
A 
if (skb can coalesce(skb, i, page, off) && 
off != PAGE SIZE) { 
/* 若 可 以 聚合 ， 则 设置 
merge 标 志 
*/ 
merge = 1 
} else if (i == MAX SKB FRAGS 
何 数据 了 。 
家 


/* 


为 了 给 新 数据 腾 出 空间 ， 需 要 将 老 数据 尽快 发 送出 去 。 


因此 设置 
PUSH 标 志 ， 并 更 新 
pusheqd_seq. 然后 跳 转 到 
new_segment， 并 申请 新 的 
skb. 
a 


tcp mark push(tp, skb); 
goto new segment; 

} else if (page) { 
/* 该 页 已 满 


$F 

if (off == PAGE SIZE) { 
put_page (page); 
TCP_PAGE (sk) = Page 
off = 0; 

} 

} else 
off = 0; 


/* 再 次 检查 复制 长 度 ， 不 能 超过 该 页 的 空闲 长 度 


NULL; 


下 


下 


A 


Wd 


eA 


i 


wy 


PUSH 标 志 


Wd 


‘A 


wy 


$ 


if (copy > PAGE SIZE - off) 
Copy = PAGE SIZE - off; 
/* 增加 发 送 缓存 内 存 占用 ， 若 超出 限制 ， 则 需要 等 待 


if (!sk wmem schedule(sk, copy)) 
goto wait for memory; 
/* 车 没有 可 用 的 页 ， 则 申请 新 的 页 


if (!page) { 
/* Allocate new cache page. */ 
if (!(page = sk stream alloc page (sk))) 
goto wait for memory; 


/* 将 数据 复制 到 页 的 相应 位 置 


err = skb copy to page nocache(sk, from, skb, 
page, off, copy); 
if (err) { 
fj 


即使 复制 失败 ， 如 果 该 页 是 新 申请 的 ， 也 应 该 让 套 接 字 拥有 该 页 ， 以 供 未 来 使 用 。 


be 

if (!TCP PAGE(sk)) { 
TCP_PAGE (sk) = page; 
TCP_OFF (sk) = 0; 


} 
goto do error; 
} 
/* Update the skb. */ 
if (merge) { 
南 


车 本 次 数据 可 以 和 最 后 一 个 分 片 合并 ， 则 更 新 最 后 一 个 分 片 的 长 度 


So 

Skb frag size add(g&skb shinfo(skb)->frags[i - 1], copy); 
} slse { 

/* 这 是 新 的 分 片 ， 需 要 为 这 个 分 片 初始 化 一 些 页 信息 





skb fill page desc(skb, i, page, off, copy); 
if (TCP PAGE (sk)) { 
/* 该 分 页 是 之 前 分 配 的 ， 因 此 增加 引用 即 可 


get_ page (page); 
} else if (off + copy < PAGE SIZE) { 
/* 车 该 分 页 是 新 分 配 的 ， 但 还 未 用 完 ， 则 增加 引用 ， 并 将 其 设置 为 套 接 字 的 


发 送 页 ， 以 便 未 米 使 用 


get_page (page); 
TCP_PAGE (sk) = page; 


下 
/* 更 新 套 接 字 的 发 送 偏 移 量 


TCP OFF (sk) = off + copy 
和 
/* 车 无 须 复制 任何 数据 ， 则 清除 


if (!copied) 
TCP_SKB_CB (skb) ->tcp_flags &= ~TCPHDR PSH; 
/* 更 新 各 种 序列 号 


tp->write seq += copy; 
TCP_SKB CB (skb)->end seq += copy’; 
skb_ shinfo (skb)->gso segs = 0; 

/* 更 新 复制 信息 


from += copy; 
copied += copy; 
/* 判断 是 否 完成 了 所 有 的 数据 拷贝 





if ((seglen -= copy) == 0 && iovlen == 0) 
goto out; 
/* 如 果 数 据 包 的 长 度 小 于 限制 ， 或 者 设置 了 


MSG_OOB 标 志 ， 则 继续 向 该 数据 包 增 加 数据 


if (skb->len < max || (flags & MSG OOB) ) 
continue; 
/* 如 果 当 前 序列 号 超过 上 次 


Push 的 序列 号 加 上 通告 窗口 的 一 半 ， 则 需要 将 本 次 数据 包 尽快 发 


送出 去 


wf 
if (forced push(tp)) { 
/* 将 本 数据 包 设置 上 


PUSH 标 志 ， 并 更 新 





Push 序 列 号 
ad 
tcp mark push(tp, skb); 
/* 将 所 有 未 决 的 数据 包 全 部 发 送出 去 
i 
_ tcp push pending frames(sk, mss now, TCP NAGLE PUSH); 
} else if (skb == tcp send head(sk)) { 
/* 如 果 套 接 字 上 只 有 当前 这 个 数据 包 ， 就 发 送 这 一 个 数据 包 
Wd 


tcp push one(sk, mss now); 
} 
continue; 
/* 等 待 发 送 缓存 


ey 
wait for sndbuf: 
/* 设置 没有 发 送 缓存 的 标志 


Ww 
Set bit (SOCK NOSPACE, &sk->sk socket->flags); 
/* 等 待 内 存 


wait for memory: 
/* 判断 是 否 已 经 复制 了 部 分 数据 


二 
if (copied) { 
/* 去 挤 


MSG_MORE 标 志 ， 表 示 尽快 将 复制 的 数据 发 送出 去 


‘A 
tcp push(sk, flags & ~MSG MORE, mss now, TCP NAGLE PUSH); 
/* 等 待 空闲 内 存 ， 可 能 进入 睡眠 状态 


bd 
if ((err = sk stream wait memory(sk, &timeo)) != 0) 
goto do error; 
/* 有 了 空闲 内 存 ， 但 


MSS 可 能 已 经 发 生 了 变化 ， 所 以 需要 重新 获取 


MSS */ 
mss now = tcp send mss(sk, &size goal, flags); 


} 
/* Out 是 正常 退出 路 径 


out: 
/* 如 果 成 功 复制 了 数据 ， 则 调用 


tcp_push 将 数据 包 发 送出 去 ， 但 不 保证 立刻 就 发 送 


要 
if (copied) 
tcp push(sk, flags, mss now, tp->nonagle); 
/* 释放 套 接 字 ， 返 回 发 送 的 字 节 数 


*/ 
release sock (sk); 
return copied; 
/* 复制 用 户 数据 错误 


do fault: 
/* 如 果 当前 


SKb 的 数据 长 度 为 


0， 则 需要 从 套 接 字 的 发 送 队列 中 将 其 删除 ， 并 释放 该 


skb */ 
if (!skb->len) { 
tcp unlink write queue (skb, sk); 
/* It is the one place in all of TCP, except connection 
* reset, where we can be unlinking the send head. 
A 
tcp check send head(sk, skb); 
Sk wmem free skbl(sk, skb); 
} 
do error: 
/* 车 出 错时 已 经 复制 了 部 分 数据 ， 则 将 已 经 复制 的 数据 发 送出 去 


ef 
if (copied) 
goto out; 
out err: 
/* 车 没有 复制 任何 数据 ， 则 获取 错误 值 ， 释 放 套 接 字 并 返回 错误 


yy 
err = sk stream errorl(sk, flags, err); 
release sock (sk); 
return err; 








站 | 























为 TCP 是 一 种 流 协 议 ， 所 以 使 用 cp_sendmsg 发 送 数据 时 ， 内 核 只 是 将 数据 包 追 加 到 套 接 字 的 发 送 队列 








了 





。 真 正 发 送 数据 的 时 刻 ， 则 是 























TCP 协 议 来 控制 的 ， 套 接 字 只 能 做 出 指示 。tcp_sendmsg 函 数 : 





void _tcp push pending frames (struct sock *sk, unsigned int cur mss, 


int nonagle) 
{ 
/* 如 果 套 接 字 是 关闭 状态 ， 则 直接 返回 


本 
if (unlikely(Sk->sk_ state == TCP CLOSE) ) 
return; 
/* tcp_write xmit 用 于 将 


了 CP 报 文 发 送 到 网 络 上 


下 
if (tcp write xmit(sk, cur mss, nonagle, 0, GFP ATOMIC)) { 
/* 如 果 没 有 要 发 送 的 数据 ， 则 重 置 零 窗口 探测 定时 器 


罗 
} 


tcp check probe timer (sk); 





面 进入 tcp_write_xmit， 代 码 如 下 : 








static int tcp write xmit(struct sock *sk, unsigned int mss now, int nonagle, 


int push one, gfp t gfp) 
{ 
struct tcp sock *tp = tcp sk(sk); 
struct sk buff *skb; 
unsigned int tso segs, sent pkts; 
int cwnd quota; 
int result; 
sent pkts = 0; 
/* 如 果 不 是 


Push_one ( 即 只 发 送 一 个 数据 包 ) ， 则 进行 


MTU 探 测 
A 
if (!push one) { 
/* 进行 
MTU 探 测 
yp 


result = tcp mtu probe (sk); 
/* 车 返回 为 


0， 则 需要 等 待 探测 结果 ， 因 此 不 能 发 送 数据 包 。 


A 
if (!result) { 
return 0; 
} else if (result > 0) { 


sent pkts = 1; 
} 
} 
/* 将 发 送 队 列 中 的 数据 包 ， 社 环 发 送出 去 


*/ 
while ((skb = tcp send head(sk))) { 
unsigned int limit; 
/* 初始 化 这 个 数据 包 的 


TSO 状态 。 
了 TSO 是 
TCP Segment Offload 的 缩写 . 当 


TCP 发 送 数 据 时 ， 需 


要 将 数据 拆 分 成 
MSS 大 小 的 数据 包 ( 即 多 个 
SKb) ， 然 后 再 增加 
TCP 首 部 、 


工 P 首 部 即 可 、 计 算 校 


验 和 等 。 而 当 网 卡 支持 
TSO 时 ， 内 核 只 需要 增加 


了 TCP 首部 即 可 ， 其 余 工作 都 交 由 网 卡 来 处 理 。 


A 
tso segs = tcp init tso segs(sk, skb, mss now); 
BUG ON(!tso segs); 
/* 检查 拥塞 窗口 。 若 为 

0， 则 不 能 发 送 

二 


cwnd quota = tcp cwnd test (tp, skb); 
if (!cwnd quota) 

break; 
/* 检查 发 送 窗口 。 若 为 


0， 则 不 能 发 送 


wy 
if (unlikely(!tcp snd wnd test(tp, skb, mss_ now))) 
break; 
if (tso segs == 1) 1 
/* 
只 有 一 个 
了 SO 数据 段 ， 进 行 


nagle 算 法 检查 。 车 返回 


0， 则 不 发 送 
A 
if (unlikely(!tcp nagle test(tp, skb, mss_ now, 
(tcp skb is last(sk, skb) ? 
nonagle : TCP NAGLE PUSH)))) 
break; 
} else { 
FT 吉本 
TSO 数 据 段 


/* 如 果 没有 设置 


Push_one 标 志 并 且 


了 SO 人 发送 算法 判断 推迟 发 送 ， 则 暂 不 发 送 这 个 数据 包 


.A 


if (!push one && tcp tso should defer(sk, skb)) 


break; 
} 
limit = mss now; 
并 


了 TSO 分 段 多 于 一 个 并 且 不 是 紧急 模式 


7 则 利用 


MSS 和 可 分 段 的 个 数 〈 拥 塞 窗口 和 


GSO 最 大 分 段 数 


量 之 间 的 最 小 值 ) 得 到 数据 的 最 长 限制 


Wd 
if (tso segs > 1 && !tcp urg mode (tp)) 


limit = tcp mss split point(sk, skb, mss_now, 


min t(unsigned int, 
cwnd quota, 
Sk->sk gso max segs)); 
/* 
车 数据 长 度 大 于 限制 ， 则 需要 分 片 。 


若 分 片 失败 ， 则 暂 不 发 送 这 个 数据 包 。 


法 
if (skb->len > limit &E& 


unlikely (tso fragment (sk, skb, limit, mss_now, 


break; 
/* 更 新 


了 CP 控 制 块 的 时 间 戳 





可 

TCP_SKB CB (skb) ->when = tcp time stamp; 

/* 发 送 数据 包 
eR 

if (unlikely(tcp transmit skb(sk, skb, 1, gfp))) 
uf 


tcp event new data sent (sk, skb); 
/* 更 新 小 包 ( 即 小 于 


MSS 大 小 ) 的 发 送 时 间 


tcp minshall update (tp, mss now, skb); 
/* 更 新 发 送 数据 包 的 数量 


Sy 
sent pkts += tcp skb pcount (skb); 
/* 如 果 设置 了 


Push_one 标 志 ， 则 只 发 送 一 个 数据 包 。 因 此 可 直接 退出 


if (push one) 
break; 


/* 如 果 当 前 处 于 拥塞 恢复 的 状态 下 ， 则 增加 这 个 状态 下 的 发 包 数量 


if (inet csk(sk)->icsk ca state == TCP CA Recovery) 
tp->prr out += sent pkts; 
/* 如 果 发 送 了 数据 ， 则 校 验 发 送 拥塞 窗口 


本 
if (likely(sent pkts)) { 
tcp_cwnd validate (sk); 


gfp))) 


return 0; 
} 
return !tp->packets out && tcp send head (sk); 





继续 往 下 跟踪 TCP 的 发 送 函 数 tcp_transmit_skb， 代 码 如 下 : 





static int tcp transmit skb (Struct sock *sk, struct sk buff *skb, int clone it, 
gfp t gfp mask) 
{ 


const struct inet connection sock *icsk = inet csk(sk); 
struct inet sock *inet; i 
struct tcp sock *tp; 

struct tcp skb cb *tcb; 

struct tcp out options opts; 

unsigned tcp options size, tcp header size; 
struct tcp md5sig key *md5; 

struct tcphdr *th; 

int err; 

BUG ON(!skb || !tcp skb pcount (skb)); 

/* 判断 拥塞 控制 算法 是 否 需要 进行 时 间 采 样 。 如 果 需 要 ， 则 获取 当前 时 间 


本 
if (icsk->icsk ca ops->flags & TCP CONG RTT STAMP) 
_net timestamp (skb); 
/* 判断 是 否 需要 克隆 这 个 数据 包 


wi 
if (likely(clone it)) { 
/* 


如 果 该 数据 包 已 经 被 克隆 了 ， 则 需要 复制 


SKB 的 私有 部 分 - 


如 未 克隆 ， 则 直接 克隆 该 数据 包 


六 
区 
if (unlikely(skb cloned(skb) ) ) 
Skb = pskb copy(skb, gfp mask) 
else 
skb = skb clone(skb, gfp mask); 
if (unlikely(!skb) ) 
return -ENOBUFS; 
} 
inet = inet sk(sk); 
tp = tcp sk(sk); 
tcb = TCB SKB CB (skb); 
memset (&opts, 0, sizeof (opts)); 
/* 根据 


TCP 包 的 类 型 计算 
了 TCP 选项 部 分 的 大 小 


下 
if (unlikely(tcb->tcp flags & TCPHDR SYN)) 
tcp options size = tcp syn options(sk, skb, &opts, &md5); 


else 
tcp options size = tcp established options(sk, skb, &opts, 
&md5); 
/* 得 到 完整 的 
了 TCP 首部 大 小 


*/ 
tcp header size = tcp options size + sizeof(struct tcphdr); 
/* 判断 是 否 有 未 确认 的 数据 包 


WA 
if (tcp packets in flight(tp) == 0) { 
/* 通知 开始 发 送 事件 


二 
tcP_ca_event (sk, CA EVENT TX STRRT) 
/* 着 设置 了 


OOO_okay 标 志 ， 则 表明 可 以 改变 发 送 队列 。 参 见 内 核 的 


XPS 发 送 机 制 
二 
Skb->ooo okay = 1; 
} else { 
/* 车 清除 


OOO_OKay 标 志 ， 则 表示 不 能 改变 发 送 队列 。 参 见 内 核 的 


XPS 发 送 机 制 


Skb->ooo_ okay = 0; 


/* 在 


Skb 中 为 


了 CP 首部 申请 空间 


家 
Skb push(skb, tcp header size) 
/* 设置 


了 TCP 首部 的 起 始 位 置 


家 
Skb reset transport header (skb) 
/* 将 数据 包 加 入 到 发 送 队 列 中 


bd 
Skb set owner w(skb, sk); 
/* 构建 


了 TCP 首部 ， 并 计算 校 验 和 


Wd 
th = tcp hdr (skb); 
th->source 
th->dest 


= inet->inet sport; 
inet->inet dport; 
th->seq htonl (tcb->seq); 
th->ack seq = htonl (tp->rcv_ nxt); 
tt belé *})th) + 5} = htons(((tcp header size >> 2) << 12) | 
tcb->tcp flags); 
if (unlikely (tcb->tcp flags & TCPHDR SYN)) { 
/* RFC1323: The window in SYN & SYN/ACK segments 
* is never scaled. 
*/ 
th->window = htons (min (tp->rcv wnd, 65535U0)); 
FF lse 
th->window 
} 


th->check 二 
th->urg ptr 到 
/* The urg mode check is necessary during a below snd una win probe */ 
if (unlikely(tcp urg mode(tp) && before(tcb->seq, tp->snd up))) { 
if (before(tp->snd up, tcb->seq + 0x10000)) { 
th->urg ptr = htons (tp->snd up - tcb->seq); 
th->urg = 1; 
} else if (after (tcb->seq + OxFFFF, tp->snd nxt)) { 
th->urg ptr = htons (OxFFFF); 





htons (tcp select window (sk)); 


07 
07 





th->urg = 1; 
} 
} 
/* 构建 
TCP 选 项 
J 
tecp options write((_ be32 *) (th + 1), tp, &opts); 
/* 如 果 不 是 
SYN 数 据 包 ， 则 
ECN 状 态 
if (likely((tcb->tcp flags & TCPHDR SYN) == 0)) 


TCP ECN send(sk, skb, tcp header size); 
#ifdef CONFIG TCP MD5SIG 


/* 计算 
TCP MD5 签名 
if (md5) { 
Sk nocaps add(sk, NETIF F GSO MASK); 
tp->af specific->calc md5 hash (opts.hash location, 
md5, sk, NULL, skb); 
} 
#endif 
/* 计算 
了 CP 的 校 验 和 
SE 
icsk->icsk af ops->send check(sk, skb); 
/* 如 果 有 


ACK 标 志 ， 则 发 送 


ACK 事 件 通知 


ff 
if (likely(tcb->tcp flags & TCPHDR ACK)) 
tcp event ack sent(sk, tcp skb pcount (skb)); 
/* 如 果 数 据 包 长 度 大 于 


TCP 首 部， 那么 自然 是 有 


了 TCP 数据 的 ， 所 以 数据 将 发 送 事件 通知 


$y 
if (skb->len != tcp header size) 
tcp event data sent (tp, sk); 
/* 增加 


了 TCP 发 送 数 据 包 的 统计 计数 


* 
/ 
if (after(tcb->end seq, tp->snd nxt) || tcb->seq == tcb->end seq) 
TCP_ADD STRATS (sock net (sk), TCP MIB OUTSEGS, 
tecp skb pcount (skb)); 
/* 调用 


ip_queue xmit 发 送 数据 报 文 


四 
/ 
err = icsk->icsk af ops->queue xmit (skb, &inet->cork.f1); 
if (likely(err <= 0)) 
return REF 
/* 判断 是 否 需 要 进入 拥塞 窗口 米 恢 复 状态 


‘A 
tcp enter cwr(sk, 1); 
/* 因为 


NET XMIT_CN 返回 值 ， 不 能 被 看 作 发 送 错误 。 


所 以 对 于 发 送 返回 的 错误 ， 需 要 调用 


Det_xmit_evVal 米 屏蔽 该 错误 


4 


return net xmit eval (err); 











至 此 ，TCP 也 完成 了 自己 的 工作 ，IP 层 将 负责 后 面 的 数据 包 发 

















13.5 ”了 "P 数 据 包 的 肥 送 流程 


前 面 两 节 分 别 分 析 学 习 了 UDP 和 TCP 的 发 送 流程 。 它 们 在 完成 各 自 的 工作 ， 并 构建 对 应 的 首部 以 
后 ， 就 将 数据 包 传 递 给 了 了 正 网 络 层 。 一 般 情 况 下 ，UDP 和 TCP 使 用 不 同 的 网 络 层 接口 函数 来 将 数据 包 传 
弟 给 网 络 层 。 下 文 将 分 别 对 UDP 和 TCP 进 行 详细 介绍 。 














> 


13.5.1 ”ip_send skb 源 码 分 析 


UDP 调用 ip_send_skb 将 数据 包 传 给 网 络 层 ， 下 面 是 其 源码 分 析 





int ip send skpb (struct sk buff *skb) 

{ 
struct net *net = sock net (skb->sk); 
int err; 
/* ip_local _ out 为 本 机 发 送 


IP 数 据 包 函数 

4 
err = ip local out (skb); 
if (err) { 


/* 发 送 错误 


6 
if (er > 0) { 
/* 利 

















net xmit _errno 转 换 发 送 错误 值 


A 


err = net xmit errno (err); 


if (err) 
IP_ INC STATS (net, IPSTATS MIB OUTDISCARDS); 
} 


return err; 





进入 ip_local_ out， 代 码 如 下 : 





int ip local out(struct sk buff *skb) 
{ 


int err; 
/* 工 LnUX 内 核 代码 充 斥 了 大 量 的 封装 函数 ， 如 


ip _ local_out、 


ip local _out, 等 等 


*/ 
/* 检查 
netfilter 在 本 机 的 发 送 路 径 
4 
err = ip local out (skb); 


err 为 


1 ， 则 表示 通过 了 


netfilter 检 查 


a 
if (likelyl(err == 1)) { 
/* 调用 路 由 输出 函数 ， 发 送 数 据 包 























经 
} 


return err; 


err = dst output (skb); 





进入 ip_local_ out， 代 码 如 下 : 





int _ip local out(struct sk buff *skb) 


/* 得 到 


IP 首 部 


* 
struct iphdr *iph = ip hdr (skb); 
/* 计算 


工 了 报 文 的 总 长 度 


只 
iph->tot len = htons (skb->len) ， 
A/* 计算 


工 了 报 文 的 校 验 和 


Eh 
ip_ send check (iph); 
/* 检查 


netfilter 的 


]OCalout 路 径 


A 


return nf hook (NFPROTO IPV4, NF_INET LOCAL OUT, skb, NULL, 
Skb dst(skb)->dev, dst output); 








Netfilter 的 源码 并 不 复杂 ， 并 且 由 于 与 当前 主题 的 相关 度 并 不 高 ， 所 以 在 此 就 不 对 Netfilter 的 相关 代 
码 进行 跟踪 分 析 了 。 我 们 可 以 假设 在 没有 使 用 Netfilter 或 没有 对 应 的 规则 时 ，nf_ hook 会 返回 1。 这 样 发 
送 数 据 包 的 关键 就 在 于 dst_output 函 数 了 。 








dst_output 函 数 的 实现 为 skb dst (skb) ->output (skb) 。 其 中 skb dst (Cskb) 为 这 个 数据 包 找到 的 路 
由 缓存 ，output 为 其 实现 发 送 功能 的 函数 指针 。 这 里 面 又 涉及 一 个 内 核 常 用 的 编程 技巧 ， 利 用 函数 指针 
将 两 个 层次 或 功能 模块 进行 隔离 解 厢 。 对 于 内 核 来 说 ， 无 论 是 要 发 送出 去 的 数据 包 ， 还 是 接收 到 的 数 
据 ， 在 构建 完 耻 报 文 后 ， 都 要 通过 查找 路 由 来 确定 下 一 步 的 流程 。 而 通过 查找 到 的 路 由 缓存 的 input 和 
output 函 数 指针 ， 就 可 以 确定 后 续 的 处 理 。 内 核 提 供 了 几 个 公共 的 路 由 输出 函数 ， 应 用 于 不 同 的 场景 的 


路 由 ， 如 dst_discard 用 于 失效 的 路 由 ，ip_rt bug 用 于 非 预 期 的 输出 ，ip_mc_output 用 于 本 机 多 播 输出 ， 而 
ip_output 则 用 于 本 机 向 外 发 送 数据 包 。 
































因此 ， 对 于 本 机 发 出 的 数据 包 ， 其 路 由 输出 函数 即 为 ip_output， 它 的 实现 非常 简单 ， 代 码 如 下 : 





int ip output (Struct sk puff *skb) 


/* 得 到 发 送 设备 


6 
struct net device *dev = skb dst (skb)->dev; 
/* 增加 


IP 数 据 包 发 送 统 计 计 数 


*/ 
IP UPD PO STATS (dev net (dev), IPSTATS MIB OUT, skb->len); 
/* 设置 数据 包 的 出 口 设备 


6 
Skb->dev = dev; 
/* 设置 数据 包 的 协议 为 


IP 协 议 


skb->protocol = htons (ETH P IP); 
/ 狂 行 


Netfilter 在 


POST ROUTING 上 的 检查 


$y 
return NF HOOK COND (NFPROTO IPV4, NF _ INET POST ROUTING, skb, NULL, deyv, 
ip finish output, 
! (IPCB (skb) ->flags & IPSKB REROUTED)); 





通过 了 Netfilter 在 POST ROUTING 上 的 检查 后 ， 数 据 包 将 进入 ip_finish_output， 代 码 如 下 : 





static int 1p finish output (struct sk buff *skb) 

{ 

#if defined (CONFIG NETFILTER) && defined (CONFIG XFRM) 
/* 如 果 是 路 由 缓存 表示 需要 变换 














并/ 
if (skb dst(skb)->xfrm != NULL) { 
/* 设置 上 重新 选 路 的 标志 





i 














IPCB (skb) ->flags |= IPSKB REROUTED; 
return dst output (skb); 
} 
#endif 
/* 如 果 数 据 包 长 度 超过 


MIU， 并 且 数 据 包 不 是 
GSO 数 据 包 


*/ 
if (skb->len > ip skb dst mtul(skb) && !skb is gso(skb) ) 1 
/* 执行 





工 了 分 片 ， 因 不 是 本 文 重点 ， 故 略 过 




















return ip fragment (skb, ip finish output2); 
} 
else 1{ 
/* 进入 真正 的 三 层 发 送 函 数 
RA 


return ip finish output2 (skb); 





继续 进入 ip_finish output2， 代 码 如 下 : 





static inline int ip finish output2(struct sk buff *skb) 
{ 

struct dst entry *dst = skb dst(skb); 

struct rtable *rt = (struct rtable *)dst; 

struct net device *dev = dst->dev; 

unsigned int hh len = LL RESERVED SPACE (dev); 

struct neighbour *neigh; 

/* 根据 路 由 类 型 是 多 播 或 广播 ， 来 增加 相应 的 计数 

















*7 
if 


(rt->rt type == RTN MULTICAST) { 


IP UPD PO STATS (dev net (dev), IPSTATS MIB OUTMCAST, skb->len); 


} else if (rt->rt type == RTN BROADCAST) 











IP UPD PO STATS (dev net (dev), IPSTATS MIB OUTBCAST, skb->len); 





/* 检查 数据 包 的 首部 是 否 还 有 存放 二 层 首部 的 空间 


迷 / 





if (unlikely(skb headroom(skb) < hh len && dev->header ops)) { 


skb */ 


*/ 


struct sk buff *skb2; 
/* 重新 申请 一 个 足够 空间 的 














Skb2 = skb realloc headroom(skb, LL RESERVED SPACE (dev)); 
if (skb2 == NULL) { 
kfree skb (skb); 


return -ENOMEM; 





} 
/* 如 果 原 数据 包 属于 某 个 套 接 字 ， 则 将 新 数据 包 也 设置 成 归属 于 这 个 套 接 字 


if (skb->sk) 
Skb set owner wl(skb2, skb->sk); 
/* 释放 原 数据 包 的 内 存 空 间 ， 让 原 数据 包 的 


SKb 指 针 指 向 新 数据 包 的 内 存 空 间 


A 


} 


kfree skb (skb); 
skb = skb2; 


rcu read lock(); 
/* 获得 路 由 的 


neighbour 信 息 


*/ 


neigh = dst get neighbour (dst); 





站 


(neigh) { 














/* 调 





neighbour 层 的 输出 接口 。 是 否 能 够 立刻 发 送 ， 依 赖 于 





neighbour 的 状态 


#7 


} 


int res = neigh output (neigh, skb); 
rcu read unlock(); 
return res; 


rcu read unlock(); 
/* 车 该 路 由 没有 


neighbour 的 信息 ， 则 输出 报错 


4 
if (net ratelimit 


() ) 














printk (KERN D 
kfree skb (skb); 
return -EINVAL; 





EBUG "ip finish output2: No header cache and no neighbour!\n"); 





13.5.2 ”ip_queue xmit 源 码 分 析 


13.5.1 节 的 ip_send_skb 是 UDP 调 用 的 地层 的 输出 接口 ， 而 TCP 调 用 的 中 层 输出 接口 则 为 
ip_queue_xmit。 下 面 来 看 看 相应 的 源码 : 





int ip queue xmit(struct sk buff *skb, struct flowi *fl) 
{ 

struct sock *sk = skb->sk; 

struct inet sock *inet = inet sk(sk); 

struct ip options rcu *inet opt; 

struct flowi4 *f14; 到 

struct rtable *rt; 

struct iphdr *iph; 

int res; 

/* 判断 数据 包 是 否 有 路 由 ， 如 果 已 经 有 了 ， 就 直接 跳 到 


packet routed */ 
rcu read lock(); 
inet opt = rcu dereference (inet->inet opt); 
£14 = &f1->u.ip4; 
rt = skb rtable (skb); 
if (rt != NULL) 
goto packet routed; 
/* 从 套 接 字 获 得 合法 的 路 由 需要 检查 是 否 过 期 ) 





大 
/ 
rt = (struct rtable *) sk dst check (sk, 0); 
if (rt == NULL) 4 0 
__be32 dagdr; 
daddr = inet->inet daddr; 
/* 如 果 有 











IP 严格 路 由 选项 ， 则 使 用 选项 中 的 地 址 作为 目的 地 址 进行 路 由 查询 














大 
if (inet opt && inet opt->opt.srr) 
daddr = inet opt->opt.faddr; 
/* 进行 路 由 查找 
去 人 
rt = ip _ route output ports(sock net (SK) ，f14， sk, 
daddr, inet->inet saddqr， 
inet->inet dport, 
inet->inet sport, 
Sk->sk protocol, 
RT_ CONN FLAGS (sk), 
Sk->sk bound dev if); 
if (IS ERR(rt)) 加 ER 
goto no route; 
/* 根据 路 由 的 接口 的 特性 设置 套 接 字 特 性 
4 


Sk setup caps(sk, &rt->dst); 


} 
/* 给 数据 包 设置 路 由 


本/ 
Skb dst set noref (skb, &rt->dst); 
packet routed: 
/* 如 果 有 


工 P 严 格 路 由 选项 


yy 
if (inet opt && inet opt->opt.is strictroute && fl14->daddr != rt->rt gateway) 
goto no route; 
/As 芬 配 


IP 首 部 和 选项 空间 


*] 
skb push(skb, sizeof(struct iphdr) + (inet opt ? inet opt->opt.optlen : 0)); 
/* 设置 


工 P 首 部 位 置 


要/ 
Skb reset network header (skb); 
/* 得 到 数据 包 





工 P 首 部 的 指针 


去 人 
iph = ip hgqr(skb) :; 
/* 构建 


IP 首 部 


*/ 
*(( bel6 *)iph) = htons((4 << 12) | (5 << 8) | (inet->tos & Oxff)); 
/* 如 不 能 分 片 ， 则 在 


工 了 首部 设置 


IP_DF 标 志 


大 
/ 
if (ip dont fragment (sk, &rt->dst) && !skb->local df) 
iph->frag off = htons (IP DF); 
else 
iph->frag off = 0; 
Bn=>t 老 1 = ip select ttl (inet, &rt->dst); 
iph->protocol Sk->sk protocol; 


iph->saddr £14->saddr; 
iph->daddr = fl14->daddr; 
/* Transport layer set skb->h.foo itself. */ 
/* 构建 
工 了 选项 


«7 


if (inet opt && inet opt->opt.optlen) { 

iph->ihl += inet opt~->opt.optlen >> 27 

ip options build(skb, &inet opt->opt, inet->inet daddr, rt, 0); 
/* 选择 合适 的 


IP identifier */ 
ip_ select ident more(iph, &rt->dst, sk, 
(skb_ shinfo(skb)->gso segs ?: 1) - 1); 
/* 根据 套 接 字 选项 ， 设 置 数据 包 的 优先 级 和 标记 


去 / 
Skb->priority = Sk->sk priority; 
Skb->mark = sk->sk mark; 
/* 发 送 数据 包 


大 
/ 
res = ip local out (skb); 
rcu read unlock(); 
return res; 
no_route: 
rcu read unlock(); 
IP_INC STATS (sock net (sk), IPSTATS MIB OUTNOROUTES); 
kfree skb (skb); 
return -EHOSTUNREACH; 








ip_queue_xmit 最 终 也 是 调用 ip_local_out 发 送 本 机 的 数据 包 。 该 函数 已 经 在 前 面 跟 踪 分 析 过 了 ， 所 以 
在 此 就 不 再 重复 了 。 





13.6 发 层 模块 数据 包 的 友 送 流程 


13.5 贡 分 析 了 卫 网 络 层 的 数据 包 的 发 送 流程 ， 并 最 终 跟 踪 到 其 调用 邻居 模块 的 发 送 接口 。 为 什么 内 
核 会 有 一 个 邻居 模块 呢 ? 本 质 上 数据 包 的 发 送 和 接收 都 依赖 于 数据 链 路 层 〈 二 层 ) 的 地 址 即 硬件 地 
址 ， 网 卡 只 接受 二 层 目的 地 址 为 自己 地 址 的 数据 包 《或 者 多 播 、 广 播 地 址 ) 。 所 谓 的 人 P 地 址 (三 层 ) 
只 是 一 个 逻辑 地 址 ， 其 实际 用 途 是 用 来 寻 径 的 。 那 么 内 核 在 发 送 数据 包 的 时 候 ， 就 需要 填充 正确 的 二 
层 人 硬件 地 址 才能 将 数据 包 成 功 地 发 送出 去 。 这 里 就 有 了 一 个 需求 ， 即 需要 将 三 层 网 络 地 址 “映射 ”为 正 
确 的 二 层 硬 件 地 址 。 对 于 IPv4 来 说 ， 这 是 由 ARP 协 议 来 实现 的 ， 而 对 于 IPv6 来 说 ， 其 邻居 发 现 协 议 是 由 
ICMPvV6 来 实现 的 。 因 此 ， 对 于 内 核 来 说 ,一 方面 是 为 了 屏蔽 不 同 的 邻居 协议 的 实现 细节 ; 男 一 方面 ， 
使 用 同一 个 邻居 模块 ， 对 外 可 以 保证 相同 的 邻居 状态 机 和 一 致 的 接口 。 
























































13.5 节 中 ， 二 层 数据 包 的 发 送 接口 为 neigh_output， 其 源码 如 下 : 





static inline int neigh output(struct neighbour xn struct sk buff *skb) 
struct hh cache *hh = &n->hh; 
1 e 


若 邻 居 状 态 为 连接 状态 : 永久 邻居 ， 不 需要 


ARP， 可 到 达 三 种 情况 ， 











并 且 存 在 硬件 地 址 ， 则 直接 调 








neigh_ hh outPut 来 发 送 。 

















不 然则 通过 邻居 的 输出 函数 发 送 -会 根据 邻居 状态 使 用 不 同 的 接口 。 


if ((n->nud _ state & NUD CONNECTED) && hh->hh len) 
return neigh hh output (hh, skb); 

else 
return n->output (n, skb); 


先 跟踪 第 一 种 情况 ， 来 查看 neigh_hh_output 的 代码 : 








static inline int neigh hh output (struct hh cache *hh, struct sk buff *skb) 
{ 


unsigned seq; 
int hh len; 

yA 加 
使 

















SeqlOock 读 取 硬 件 地 址 。 

















Seq]ock 一 般 用 在 频繁 读 操作 ， 偶 尔 写 操作 的 情况 下 。 读 操作 并 不 会 真正 地 上 锁 ， 因 此 不 会 阻塞 其 他 读 操 





























作 和 写 操作 ， 并 通过 序号 来 保证 读 出 数据 的 完整 性 ， 写 操作 会 使 月 








Spinlock 来 保证 同一 时 间 只 有 一 个 写 


操作 。 


#/ 
de +4 
int hh alen; 
seq = read seqbegin(&hh->hhn lock); 
hh len = hh->hh len; | 
hh alen = HH DATA ALIGN (hh len); 
memcpy (skb->data - hh alen, hh->hh data, hh alen); 
} while (read seqretry(&hh->hh lock, seq)); 
/* 保存 硬件 地 址 


多 
skb push(skb, hh len); 
/* 调用 底层 发 送 数据 包 接口 




















yy 
} 


return dev queue xmit (skb); 








下 面 再 来 分 析 邻 居 在 不 同 状 态 下 的 发 送 接 口 ， 在 此 ， 以 IPv4 的 ARP 协 议 为 例 来 进行 分 析 。 


首先 我 们 来 看 看 NUD_NOARP 状 态 ， 代 码 如 下 : 





neigh->nud state = NUD NOARP; 
neigh->ops = &arp direct ops; 
neigh->output = neigh direct output; 





在 NUD_NOARP 状 态 下 ，neigh 的 发 送 接口 为 neigh_direct_output， 代 码 如 下 。 





int neigh direct output (Struct neighbour *neigh, struct sk buff *skb) 


{ 
} 


return dev queue xmit (skb); 





这 个 函数 “ 码 如 其 名 ”， 就 是 直接 调用 底层 的 发 送 接口 。 


再 来 看 看 NUD VALID 状态 和 其 余 状 态 ， 代 码 如 下 : 





if (dev->header ops->cache) 
neigh->ops = &arp hh ops; 

else 
neigh->ops = &arp generic ops; 


if (neigh->nud state & NUD VALID) 

neigh->output = neigh->ops->connected output; 
else 

neigh->output = neigh->ops->output; 





若 网 卡 提供 了 首部 缓存 的 功能 ， 则 邻居 的 操作 函数 为 arp_hh_ops， 不 然则 为 arp_generic_ops。 对 于 
arp_generic_ops 来 说 ， 知 邻居 状态 为 NUD VALID， 则 输出 函数 为 neigh_ connected_output 〈 与 
NUD NOARP 状 态 相 同 ) ， 其 余 状 态 则 为 neigh resolve_output， 代 码 如 下 : 





int neigh resolve output (struct neighbour *neigh, struct sk buff *skb) 
{ 
struct dst entry *dst = skb dst (skb); 
int rc = 07 
if (!dst) 
goto discard; 
/* 根据 具体 的 邻居 发 现 协议 ， 发 送 探测 邻居 数据 包 。 对 于 


工 PV4 来 说 ， 就 是 


ARP 请 求 。 如 果 成 功 得 到 邻 


居 的 地 址 ， 则 返回 成 功 〈 数 值 


0) ， 不 然则 返回 错误 值 


*/ 
if (!Ineigh event send(neigh, skb)) { 
/* 有 了 邻居 即 对 端 硬件 地 址 ， 就 可 以 发 送 数据 包 了 

















$$ 
int err; 
struct net device *dev = neigh->dev; 
unsigned int seqg; 
/* 如 果 网 卡 有 地 址 缓存 功能 ， 并 且 邻 居 模 块 没有 对 应 的 硬件 地 址 ， 则 调用 网 卡 功能 ， 填 充 二 层 硬件 地 址 


if (dev->header ops->cache && !neigh->hh.hh len) 
neigh hh init (neigh, dst); 
/* 下 面 的 代码 与 

















neigh_ hh _output 类 似 , 利 





Seql1ock 在 无 锁 的 条 件 下 ， 保 证 二 层 地 址 读 取 的 完整 性 。 


#7 

do { 
__Skb pull(skb, skb network offset (skb)); 
sedq = read seqbegin (gneigh->ha lock); 
err = dev hard header (skb, dev, ntohs (skb->protocol), 

neigh->ha, NULL, skb->len); 
} while (read seqgretry(&neigh->ha lock, seqg)); 
/* 车 成 功 读 取 了 硬件 地 址 ， 则 调用 底层 发 送 函 数 ， 将 数据 包 发 送出 去 。 





























4 
if (err >= 0) 
rc = dev queue xmit (skb); 
else 
goto out kfree skb; 
} 
oOut: 
returini. Le» 
drscard: 
NEIGH PRINTK1 ("neigh resolve output: dst=%p neigh=%p\n", 
dst, neigh); 
out kfree skb: 
rc = -EINVAL; 
kfree skb (skb); 
goto out; 


} 





邻居 模块 除了 相应 的 发 送 过 程 外 ， 更 为 重要 的 是 邻居 模块 状态 变迁 的 状态 机 ， 以 及 邻居 发 现 协议 
的 实现 。 但 是 这 两 部 分 与 本 章 的 主题 关联 并 不 大 ， 代 码 也 不 复杂 ， 熟 悉 相 关 协 议 的 读者 可 以 很 容易 看 
懂 该 部 分 代码 。 








邻居 模块 调用 的 底层 发 送 接口 为 dev_queue_xmit， 实 质 上 数据 包 会 首先 进入 内 核 的 TC 模块 的 队列 
《默认 情况 下 ， 网 卡 使 用 的 TC 队列 为 PFIFO_FAST 队 列 ) ， 然 后 根据 队列 算法 ， 让 合适 的 数据 包 出 队 
(之 所 以 说 合适 的 ， 是 因为 不 同 的 TC 队列 ， 其 出 队 的 算法 不 同 ) ， 并 调用 网 卡 的 发 送 函数 ， 将 数据 包 
发 送 到 网 卡 。 如 果 这 时 网 卡 满足 发 送 条 件 ， 则 数据 包 将 会 被 真正 地 发 送出 去 。 知 不 满足 发 送 条 件 ， 则 
将 利用 发 送 软 中 断 ， 过 段 时 间 再 进行 下 一 轮 尝 试 。 




















第 14 章 ”网络 通信 : 





数据 报 文 的 接收 


第 13 章 完成 了 对 数据 包 发 送 流程 的 分 析 和 学 习 ， 本 章 则 要 学 习 数 据 包 的 接收 过 程 ， 同 样 也 从 应 用 








层 开始 入 手 ， 然 后 深入 到 内 核 的 实现 代码 ， 从 而 真正 到 


_ 吉 
章 。 


LE 解 接收 数据 的 接口 。 本 章 也 是 网 络 通信 的 最 后 


14.1 系统 调用 接口 











与 发 送 类 似 ， 内 核 也 提供 了 多 个 接收 数据 的 系统 调用 接口 ， 接 口 定 义 如 下 : 











#include <sys/types.h> 
#include <sys/socket.h> 
ssize t recv(int sockfd, void *buf, size t len, int flags); 
ssize t recvfrom(int sockfd, void *buf, size t len, int flags, 
加 struct sockaddr *src addr, socklen 七 *addrlen); 
ssize 七 fecvmsg(int sockfd, struct msghdr *msg, int flags); 











与 send 类 似 ，recvy 一 般 也 是 面向 连接 的 套 接 字 。 原 因 在 于 ， 对 于 非 面 向 连接 的 套 接 字 来 说 ， 若 使 用 
recv 接 收 数据 ， 通 过 该 接口 将 不 能 获得 发 送 端的 地 址 ， 也 就 是 说 不 知道 这 个 数据 是 谁 发 过 来 的 。 所 以 ， 
如 果 使 用 者 不 关心 发 送 端 信息 ， 或 者 该 信息 可 以 从 数据 中 获得 ， 那 么 recv 接 口 同样 也 可 以 用 于 非 面向 连 
接 的 套 接 字 。 再 来 看 看 recvffom， 它 会 通过 额外 的 参数 src_addr 和 addrlen， 来 获得 发 送 方 的 地 址 ， 其 中 
需要 注意 的 是 addrlen， 它 既是 输入 值 又 是 输出 值 。 最 后 是 recvmsg， 它 与 sendmsg 一 样 ， 把 接收 到 的 数据 
和 地 址 都 保存 在 了 msg 中 。 其 中 msg.msg name 和 msg.msg len 用 于 保存 接收 端 地 址 ， 而 msg.msg iov 用 于 保 
存 接收 到 的 数据 。 这 三 个 系统 调用 与 对 应 的 发 送 接口 一 样 ， 都 支持 设置 标志 位 flags 一 一 都 是 比较 现代 
的 接口 设计 方法 。 























14.2 


第 13 章 中 ， 几 个 不 同 的 发 送 数据 包 的 系统 调用 ， 最 终 都 是 通过 公 


么 
收 数据 包 的 系统 调用 ， 我 们 相信 它们 也 是 殊途同归 ， 最 后 会 进入 到 一 个 公共 的 函数 中 。 接 下 来 ， 跟 踪 14.1 节 


数据 包 从 内 核 空间 到 用 户 空间 的 注 程 











三 个 系统 调用 的 实现 ， 来 证 明 我 们 的 猜想 。 


首先 是 recv 的 源码 : 


^\ 二 


~、 


的 函数 sock sendmsg 来 完成 的 。 那 么 对 于 接 


介绍 的 





asm. 





linkage long sys recvl(int fd, void user *ubuf, size t size, 
unsigned flags) 


return sys recvfrom(fd, ubuf, size, flags, NULL, NULL); 








代码 很 简单 ，recv 完 全 是 通过 调用 sys_recvfrom 来 实现 的 ， 仅 仅 是 将 sys_recvfrom 的 最 后 两 个 参数 设置 为 0 而 已 。 





那么 接 下 来 就 进入 recvfrom 的 源码 : 








SYSCALL DEFINE6 (recvfrom, int, fd, void _user *, ubuf, size t, 


unsigned, flags, struct sockaddr user *, adggr, 
int _user *, addr len) 


struct socket *sock; 

struct iovec iov; 

struct msghdr msg; 

struct sockaddr storage address; 
int err, err2; 

int fput needed; 

/* 限制 读 取 字 节 长 度 的 最 大 值 为 整数 的 最 大 值 


INT MAX */ 


*/ 


4 


4 


if (size > INT MAX) 
size = INT MAX; 
/* 从 文件 描述 符 得 到 套 接 字 结构 


sock = sockfd lookup light (fd, &err, &fput needed); 
if (!sock) 

yoto out} 
/* 控制 信息 清 堆 


msg.msg control = NULL; 
msg.msg controllen = 0; 
/* 设置 消息 的 数据 段 信息 


msg.msg iovlen = 1; 
msg.msg iov = &iov; 
iov.iov len = size; 
iov.iov base = ubuf; 
/* 设置 消息 的 存储 地 址 信息 


msg.msg name = (struct sockaddr *)&address; 
msg.msg namelen = sizeof (address); 
/* 如 果 套 接 字 设置 了 


O_NONBLOCK 标 志 ， 即 非 阻塞 标志 ， 则 设置 


MSG_DONTWAIT 标 志 ， 表 示 此 次 接收 消息 ， 无 须 等 竺 


size, 


家 人 
if (sock->file->f flags & O NONBLOCK) 
flags |= MSG DONTWAIT; 
/* 调用 


SOCk _recvmsg 接 收 数据 


* 
err = sock recvmsg (sock, &msg, size, flags); 
/* 将 地 址 信息 复制 到 用 户 空间 


天 六 
if (err > 
err2 


0 && addr != NULL) { 

move addr to user((struct sockaddr *) &address, 
msg.msg namelen, addr, addr len); 

if (err2 < 0) 加 加 
err = err2; 


} 

fput light (sock->file, fput needed); 
out: 

return err? 








后 面 的 调用 流程 则 为 sock recvmsg-> sock recvmsg—> sock recvmsg nosec。 











下 面 跟踪 第 三 个 接收 数据 包 的 系统 调用 recvmsg， 代 码 如 下 : 





SYSCALL DEFINE3(recvmsg, int, fd, struct msghdr _user * msg, 
unsigned int, flags) 
{ 
int fput needed, err; 
struct msghdr msg_ sys; 
/* 从 文件 描述 符 


下 gd 获得 套 接 字 


大 
人 
struct socket *sock = sockfd lookup light (fd, &err, &fput needed); 
if (!sock) 
goto out; 
/* __Sys_recvmsg 用 于 实现 接收 数据 


4 
err = sys recvmsg(sock, msg, &msg sys, flags, 0); 
/* 释放 


Ed 引用 (如 果 需 要 的 话 ) ， 这 也 是 


Eput light 与 








Fput 的 区 别 


eh 
fput light (sock->file, fput needed); 
out: 
Peturen Cer 


} 





下 面 进入 _ sys_recvmsg， 代 码 如 下 : 








static int _sys recvmsg(struct Socket *sock, struct msghdr _user *msg, 
struct msghdr *msg sys, unsigned flags, int nosec) 

{ 
struct compat msghdr _user *msg compat = 
(struct compat msghdr _user *)msg; 

struct iovec iovstack[UIO FASTIOV]; 

struct iovec *iov = iovstack; 

unsigned long cmsg ptr; 

int err, iov size, total len, len; 

/* kernel mode address */ 

struct sockaddr storage addr; 

/* user mode address pointers */ 

struct sockaddr user *uadgr; 

int _ user xuaddr len; 

/* 将 消息 头 从 用 户 空间 复制 到 内 核 空间 


Bd 
if (MSG CMSG COMPAT & flags) { 
if (get compat msghdr (msg sys, msg compat)) 
return -EFAULT; 
} else if (copy from user(msg sys, msg, sizeof (struct msghdr))) 
return -EEFEAULTI} 
err = -EMSGSIZE; 
/* 检查 数据 段 的 个 数 
人 


if (msg sys->msg iovlen > UIO MAXIOV) 
goto Cut 

i* 

为 了 避免 频繁 申请 内 存 ， 内 核 在 栈 上 申请 了 


UIO_FASTIOV 大 小 的 


iovec 数 组 以 供 


OV 使 用 。 当 数据 段 个 数 


超过 


UIO_FASTIOV 时 ， 就 需要 动态 申请 内 存 。 














Ry 
err = -ENOMEM; 
iov size = msg sys->msg iovlen * sizeof(struct iovec); 
if (msg sys->msg iovlen > UIO FASTIOV) { 
iov = sock kmalloc(sock->sk, iov size, GFP KERNEL); 
1 (OV) 
goto out; 
} 
/* 验证 用 户 传递 的 数据 段 参数 和 地 址 参数 
eh 
uaddr = (_ force void _user *)msg sys->msg name; 


uaddr len = COMPAT NAMELEN (msg); 
if (MSG CMSG COMPAT & flags) { 
err = verify compat iovec(msg sys, iov, 
(struct sockaddr *) &addr, 
VERIFY WRITE); 
} else 
err = verify iovec(msg sys, iov, 
(struct sockaddr *)&addr, 
VERIFY WRITE); 
if (err < 0) 
goto out freeiov; 
total len = err; 
cmsg ptr = (unsigned long)msg sys->msg control; 
/* 确保 消息 标志 中 只 有 内 核 支持 的 两 个 标志 


要 办 
msg_sys->msg flags = flags & (MSG CMSG CLOEXEC|MSG CMSG COMPAT); 
/* 如 果 套 接 字 为 非 阻塞 ， 则 设置 标志 位 为 不 等 待 〈 非 阻塞 ) 


从 
if (sock->file->f flags & O NONBLOCK) 
flags |= MSG DONTWAIT; 
/* 根据 安全 检查 标志 ， 调 用 不 同 的 接收 函数 ， 但 最 终 都 会 调用 到 


sock recvmsg */ 
err = (nosec ? sock recvmsg nosec : sock recvmsg) (sock, msg sys, 
total len, flags); 
if (err < 0) 
goto out freeiov; 
|e = El 
/* 将 发 送 端的 地 址 复制 到 用 户 空间 


4 
if (uaddr != NULL) { 
err = move addr to user((struct sockaddr *)&addr， 
msg_sys->msg namelen, uaddr, 
uaddr len); 
if (err < 0) 
goto out freeiov; 





由 上 面 的 代码 可 以 看 出 ， 内 核 提供 的 三 个 接收 数据 包 的 系统 调用 ， 最 终 确实 如 我 们 所 期 望 的 ， 都 会 走 到 一 个 共 








同 的 函数 _sock recvmsg_ nose 里 。 下 面 来 看 一 下 这 个 函数 ， 代 码 如 下 : 














| 





static inline int _sock recvmsg nosec(struct kiocb *iocb, struct socket *sock,struct msghdr *msg, Size t size, int flags) 


{ 
struct sock iocb *si = kiocb to siocb (iocb) ; 
sock update classid(sock->sk); 
/* 设置 套 接 字 异步 


工 O 信 息 


光 米 
Si->Sock = sock; 
si->scm = NULL; 
Si->msg = msg; 
si->size = size; 
si->flags = flags; 
/* 根据 不 同 的 套 接 字 类 型 ， 调 用 不 同 的 数据 接收 函数 


过 人 
return sock->ops->recvmsg (iocb, sock, msg, size, flags); 








根据 上 面 的 代码 ， 后 面 的 接收 流程 就 要 依赖 于 具体 的 协议 实现 了 。 











14.3 UDP 数据 包 的 接收 流程 


首先 ， 我 们 来 分 析 一 下 相对 简单 的 UDP 协议 的 数据 包 接 收 流程 ， 代 码 如 下 : 





int udp recvmsg (Struct kiocb *iocb, struct sock *sk, struct msghdr *msg, 
size t len, int noblock, int flags, int *addr len) 
{ 


struct inet sock *inet = inet sk(sk); 
Xe 


Sin 指 向 

















msg_name， 用 于 保存 发 送 端 地 址 


大 
/ 
struct sockaddr in *sin = (struct sockaddr in *)msg->msg name; 
struct sk buff *skb; 
unsigned int ulen, copied; 
int peeked; 
int err; 
int is udplite = IS UDPLITE (sk); 
bool slow; 
/* 车 





addr_len 不 为 




















NULL， 即 用 户 传递 了 地 址 长 度 参数 。 进 入 了 具体 的 协议 层 ， 已 经 可 以 明确 地 址 的 长 度 信息 了 。 





*#/ 
if (addr len) 
*addr len = sizeof (*sin); 
/* 用 户 设置 了 



































Ff 


MSG_PERRQUEUE 标 志 ， 











于 接收 错误 消息 。 因 为 这 个 应 用 并 不 广泛 ， 因 此 在 此 忽略 这 种 情况 ， 不 进入 该 函数 。 











大 
/ 
if (flags & MSG_ ERROQOUEUE,) 
return ip recv error(sk, msg, len); 
try again: 
/* 接收 了 一 个 数据 报 文 





*/ 
Skb = skb recv datagram(sk, flags | (noblock ? MSG DONTWAIT : 0), 
&peeked, &err); 
/* 若 没 有 收 到 报 文 ， 则 直接 退出 


*/ 
if (!skb) 
goto out; 
/* 得 到 


UDP 的 数据 长 度 


#/ 
ulen = skb->len - sizeof (struct udphdr); 
/* 要 复制 的 长 度 被 初始 化 为 用 户 指定 的 长 度 




















0 
copied = len; 
/* 若 复 制 长 度 大 于 





UDP 的 数据 长 度 ， 则 调整 复制 长 度 为 数据 长 度 。 若 复制 长 度 小 于 数据 长 度 ， 则 设置 标志 


MSG _TRUNC， 表 示 数 据 发 生 了 截断 。 





*] 
if (copied > ulen) 
copied = ulen; 
else if (copied < ulen) 
msg->msg flags |= MSG TRUNC; 
J 
如 果 发 生 了 数据 截断 ， 或 者 我 们 只 需要 部 分 覆盖 的 校 验 和 ， 那 么 就 在 复制 前 进行 校 验 。 





#/ 
if (copied < ulen || UDP SKB CB (skb)->partial cov) { 
/* 进行 
UDP 校 验 和 校 验 


二 
if (udp lib checksum complete (skb)) 
goto csum copy err; 


} 
/* 判断 是 否 需 要 进行 校 验 和 校 验 


7 
if (skb csum unnecessary (skb)) { 
/* ” 若 不 需要 进行 校 验 ， 则 直接 复制 数据 包 内 容 到 





msg_iov 中 


* 
err = Skb copy datagram iovec(skb, sizeof(struct udphdr), 
msg->msg_iov, copied); 
} 
else 1{ 
/* 复制 数据 包 内 容 的 同时 ， 进 行 校 验 和 校 验 


党 
/ 
err = Skb copy and csum datagram iovec (skb, 
sizeof (struct udphdr), 
msg->msg iov); 
if (err == -EINVAL) - 
goto csum copy err; 








} 
/* 复制 错误 检查 


if (err) 
goto out free; 
/* 如 果 不 是 


Peek 动 作 ， 则 增加 相应 的 统计 计数 


4 
If (!peeked) 
UDP_INC_ STATS USER(sock net (sk), 
UDP MIB INDATAGRAMS, is udplite); 
/* 更 新 套 接 字 的 最 新 的 接收 数据 包 时 间 蕉 及 丢 包 消 息 





2 
sock recv ts and drops(msg, sk, skb); 
/* 如 果 用 户 指定 了 保存 对 端 地 址 的 参数 ， 则 从 数据 包 中 复制 地 址 和 端口 信息 























ig on 十 
sin->sin family = AF INET; 
sin->sin port = udp hdr (skb)->source; 
sin->sin addr.s addr = ip hdr (skb)->sadgddr; 
memset (sin->sin zero, 0, sizeof (sin->sin zero)); 





} 
/* 设置 了 接收 控制 消息 


if (inet->cmsg flags) { 
/* 接收 控制 消息 如 


TTL, 


了 TOS 等 


ip_ cmsg recv (msg, skb); 
} 
/* 设置 了 已 复 制 的 字 节 长 度 


二 1/ 
err = copied; 
if (flags & MSG TRUNC) 
err = ulen; 
out free: 
/* 释放 接收 到 的 这 个 数据 包 


*/ 
skb free datagram locked(sk, skb); 
out: 
/* 返回 读 取 的 字 节 数 


*/ 
return err; 
/* 错误 处 理 


*7 


从 上 面 的 代码 中 ， 我 们 可 以 得 到 一 个 大 部 分 书 中 都 不 会 涉及 的 信息 。 先 想 一 想 ， 在 读 取 一 个 UDP 
数据 包 时 ， 如 果 传 递 给 接口 的 缓存 空间 小 于 UDP 数据 包 的 实际 大 小 时 ， 结 果 会 是 什么 样 的 呢 ? 对 于 TCP 
来 说 ， 这 个 问题 比较 简单 ， 因 为 其 是 流 协议 ， 没 有 数据 报 文 边界 ， 所 以 这 次 未 读 取 的 数据 ， 会 在 下 一 
次 读 取 时 被 复制 。 但 是 UDP 是 基于 数据 包 的 ， 从 上 面 的 内 核 源码 可 以 看 到 ， 当 缓存 小 于 UDP 报 文 的 实际 
大 小 时 ， 内 核 会 将 报 文 截断 ， 只 复制 缓存 大 小 的 数据 ， 同 时 设置 FMSG_TRUNC 截 断 标 志 。 这 种 情 
况 ， 是 很 难 从 书本 上 了 解 到 的 ， 只 有 通过 阅读 源码 才能 理解 其 中 的 奥妙 。 























再 进入 _skb_ recv_datagram， 来 查看 UDP 是 如 何 接收 报 文 的 ， 代 码 如 下 : 








struct sk buff * skb recv datagram(struct Sock *sk, unsigned flags, 
int *peeked, int *err) 
{ 





struct sk buff *skb; 
long timeo; 
/* 检查 套 接 字 是 否 出 错 


大 
/ 
int error = sock error (sk); 
if (error) 加 
goto no packet; 
/* 得 到 超时 时 间 ， 如 果 设 置 了 


MSG_DONTWAIT， 则 超时 为 


























0 
timeo = sock rcvtimeo(sk, flags & MSG DONTWAIT); 
do { 
unsigned long cpu flags; 
spin lock irqsave(&sk->sk receive queue.lock, cpu flags); 
/* 得 到 接收 队列 的 第 一 个 数据 包 
4 
Skb = skb peek(&sk->sk receive queue); 
if (skb) { 
*peeked = skb->peeked; 
/* 如 果 只 是 查看 动作 ， 则 要 增加 数据 包 的 引用 计数 ， 并 不 用 把 数据 包 从 队列 中 移 除 。 
A 


if (flags & MSG PEEK) { 
skb->peeked = 1; 
atomic inc(&skb->users); 
} else 1{ 
/* 将 数据 包 从 接收 队列 中 删除 





“7 


skb unlink(skb, &sk->sk receive queue); 
} 
} 
spin unlock irqrestore(&sk->sk receive queue.lock, cpu flags); 
/* 得 到 了 数据 包 ， 直 接 返回 


*/ 
if (skb) 
return skb; 
/* 若 已 经 没有 了 剩余 的 超时 时 间 ， 则 跳 转 到 


DO_Packet 并 返回 





NULL */ 
error = -EAGAIN; 
if (!timeo) 
goto no packet; 
/* 使 





task 在 套 接 字 上 等 待 


大 
/ 
} while (!wait for packet (sk, err, &timeo)); 
return NULL; 
no packet: 
~ *err = error; 
return NULL; 











如 果 当 前 的 UDP 套 接 字 没有 数据 包 ， 则 会 进入 wait for_ packet 进 行 等 待 ， 代 码 如 下 ; 





static int wait for packet (struct sock *sk, int *err, long *timeo p) 


{ 
int error; 
/* 定义 等 待 队列 和 回调 的 唤醒 函数 


*7 





DEFINE WAIT FUNC (wait, receiver wake function); 
/* 初始 化 等 待 队列 ， 需 要 注意 的 是 











TASK_INTERRUPTIBLE。 这 表明 进程 在 睡眠 等 待 时 ， 是 可 以 被 中 断 的 。 


4 
prepare to wait exclusive(sk sleep(sk), &wait, TASK INTERRUPTIBLE); 
/* 检查 套 接 字 是 否 出 错 ， 如 被 











RESET。 如 有 错误 ， 则 直接 退出 。 





*y 
error = sock error (sk); 
if (error) 
goto out err; 


/* 车 接收 队列 不 为 空 ， 则 可 以 直接 退出 


Se 


if (!skb queue empty(&sk->sk receive queue) ) 
goto out; 
/* 检查 套 接 字 是 否 已 经 做 了 接收 半 关闭 


小 
if (sk->sk shutdown & RCV_SHUTDOWN) 
goto out noerr; 
/* 如 果 套 接 字 是 基于 连接 的 ， 并 且 不 是 处 于 已 连接 状态 或 监听 状态 ， 则 报错 退出 


大 
/ 
error = -ENOTCONN; 
if (connection based(sk) && 
! (sk->sk state == TCP ESTABLISHED || sk->sk state == TCP LISTEN)) 
goto out err; 
/* 是 否 有 未 处 理 的 信号 


大 
/ 
if (signal pending (current)) 
goto interrupted; 
error = 0; 
/* 将 当前 进程 调度 出 去 ， 直 到 超时 ， 即 进程 已 经 休眠 了 设 定 的 超时 时 间 。 但 是 由 于 某 些 原因 ， 进 程 被 提前 唤 


醒 ， 所 以 需要 保存 返回 的 时 间 


x 七 rmneO_P， 表 示 还 剩 下 多 少时 间 。 


大 
4 

*timeo p = Schedule timeout (*timeo p); 
out: 

finish wait (sk Sleep (sk), &wait); 
return error; 加 





interrupted: 
error = sock intr errno(*timeo p); 
out err: 
x*err = error; 
goto. outs 
out noerr: 
~*err = 0; 


error = 1; goto out; 





至 此 ，UDP 数 据 包 的 接收 流程 已 经 跟踪 完毕 。 但 是 这 里 遗留 了 一 个 问题 : 在 上 面 的 代码 中 ， 报 文 
是 从 接收 队列 中 获得 的 ， 但 是 数据 包 又 是 如 何 被 保存 到 套 接 字 的 接收 队列 中 的 呢 ? 这 个 问题 留 到 后 面 











14.4 TCP 数据 包 的 接收 流程 


14.3 节 跟踪 了 UDP 数 据 包 的 接收 流程 ， 本 节 来 分 析 一 下 TCP 数 据 包 的 接收 流程 。 根 据 TCP 协 议 的 复杂 性 可 想 而 知 ， 











其 接收 流程 自然 也 比 UDP 要 繁琐 得 多 。 








int tcp recvmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg, 
size t len, int nonblock, int flags, int *addr len) 


{ 
struct tcp sock *tp = tcp sk(sk); 
int copied = 0; 
U32 peek seq; 
U32 *seq; 
unsigned long used; 
int err; 


int target; /* Read at least this many bytes */ 


long timeo; 

struct task struct *user recv = NULL; 
int copied early = 0; 

struct sk buff *skb; 

u32 urg hole = 0; 

/* 对 套 接 字 上 锁 





Bd 
lock sock (sk); 
err = -ENOTCONN; 
/* 如 果 套 接 字 为 监听 状态 ， 则 跳 转 到 退出 分 支 


if (sk->sk state == TCP _ LISTEN) 
goto out; 
/* 与 


UDP 类 似 ， 得 到 超时 时 间 








timeo = sock rcvtimeo(sk, nonblock); 
/* 设置 了 
MSG_OOB 标 志 ， 即 带 外 数据 ， 对 于 


了 TCP 来 说 ， 就 是 接收 紧急 数据 


4 
if (flags & MSG OOB) 
goto recv urg; 
/* 得 到 与 预 读 取 


了 TCP 数据 相对 应 的 序列 号 


四 
* 
seq = &tp->copied seq; 
if (flags & MSG PEEK) { 
peek seq = tp->copied seq; 
seq = &peek seq; 


TCP 是 流 协议 ， 数 据 没有 边界 ， 所 以 需要 计算 接收 数据 的 最 小 长 度 。 


1) 车 设置 了 


MSG_WAITALL， 则 目标 为 用 户 指定 的 长 度 ; 


2) 不 然 ， 则 选择 套 接 字 的 低 水 线 和 用 户 指定 长 度 的 最 小 值 ， 


3) 如 果 第 二 种 情况 的 最 小 值 为 


0， 则 数据 长 度 为 


1 字 节 ; 


A 


/* 
CONEFIG_NET_DMR 编 译 选项 的 含义 为 


target = sock rcvlowat (Sk，flags & MSG WAITALL, 


TCP 接 收复 制 印 载 。 


利用 


len); 


DMA 米 将 接收 到 的 数据 复制 到 用 户 空间 ， 从 而 节省 


CPU. 


ba 
#ifdef CONFIG NET DMA 
tp->ucopy.dma chan = NULL; 
preempt disable(); 
Skb = skb peek tail(&sk->sk receive queue); 
{ 
int available = 0; 
/* 接收 队列 中 有 未 读 的 数据 包 


本 
if (skb) { 
/* 计算 可 读 的 数据 量 


灵 
/ 
available = TCP SKB CB (skb) ->seq + skb->len - (*seq); 
} 
if ((available < target) && 
(len > sysctl tcp dma copybreak) && !(flags & MSG PEEK) && 
lsysctl] tcp low latency && 
dma find channel (DMA MEMCPY)) { 
preempt _ enable no resched(); 
/* 确定 


DMA 要 使 用 的 数据 段 


wf 
tp->ucopy.pinned list = 
dma pin iovec pages (msg->msg iov, len); 
} else { 
preempt enable no resched(); 
} 
#endif 
dof 
U32 offset; 
/* 判断 是 否 正在 读 取 紧 急 数据 
wf 
if (tp->urg data && tp->urg seq == *seq) { 
/* 如 果 已 经 读 取 了 一 定量 的 数据 ， 则 结束 读 取 
A 
if (copied) 
break; 
/* 如 果 有 未 处 理 的 信号 ， 也 结束 读 取 
wf 
if (signal pending(current)) { 
copied = timeo ? sock intr errno(timeo) : -EAGAIN; 
break; 
} 
} 
/* 遍历 接收 队列 
二 
Skb queue walk(&sk->sk receive queue, skb) { 
/* Now that we have two receive queues this 
* shouldn't happen. 
ea 
if (WARN (before(*seq, TCP_ SKB CB (skb)->seq), 
"recvmsg bug: copied %X seq %X rcvnxt %X f1 %X\n", 
*seq, TCP_ SKB CB (skb)->seq, tp->rcv nxt, 
flags)) 
break; 
/* 取得 在 数据 包 中 的 偏 移 ， 即 上 次 没有 将 这 个 数据 包 读 取 完毕 
*/ 


offset = *seq - TCP_ SKB CB (skb)->seq; 
/* syn 标 志 会 占用 一 个 


Sequence， 所 以 偏 移 减 一 





wf 
if (tcp hdr (skb)->syn) 
offset 
/* 车 仿 移 小 于 数据 包 长 度 ， 则 这 个 数据 包 就 是 要 接收 的 数据 包 
i 


if (offset < skb->len) 
goto found ok skb; 
/* 如 果 当 前 数据 包 包含 


了 IN 标志 ， 则 跳 转 到 


fin 处 


x 
Ca 
if (tcp hdr (skb)->fin) 
goto found fin ok; 
WARN (! (flags & MSG PEEK), 
"recvmsg bug 2: copied %X seq %X rcvnxt %X fl S$X\n", 


*seq, TCP SKB CB(skb)->seq, tp->rcv nxt, flags); 


: 
/* 若 已 经 复制 了 超过 目标 的 数据 并 且 有 积压 的 数据 ， 则 立刻 跳出 ， 并 尝试 处 理 积压 数据 。 





if (copied >= target && !sk->sk backlog.tail) 
break; 
/* 
这 里 针对 是 否 已 经 复制 了 部 分 数据 做 了 条 件 判断 ， 而 且 每 个 分 支 中 都 有 相似 的 条 件 判断 ， 为 什么 要 
分 两 种 情况 呢 ? 因为 在 读 取 过 程 中 ， 如 果 发 生 了 同样 的 错误 ， 只 读 取 了 部 分 数据 ， 那 么 系统 调用 的 
数 ， 而 未 读 取 任何 数据 ， 则 返回 
一 1 错误 。 


a 
if (copied) { 
/* 


已 复制 了 部 分 数据 ， 检 查 下 面 几 个 条 件 : 


1) 套 接 字 出 错 。 


2) 连接 已 经 关闭 。 


3) 套 接 字 关闭 了 接收 端 


4) 已 经 超时 。 


5) 有 待 处 理 的 信号 。 


若 有 一 个 条 件 符合 ， 则 跳出 接收 数据 循环 。 


WE 

if (sk->sk err || 
Sk->sk state == TCP CLOSE || 
(sk->sk shutdown & RCV_SHUTDOWN) || 
!timeo || 
signal pending (current)) 
break; 

} else { 
/* 
若 套 接 字 设 置 了 


SOCK_DONE 标 志 ， 则 跳出 循环 。 


对 于 


TCP 来 说 ， 被 动 关闭 时 ， 套 接 字 会 被 设置 上 这 个 标志 。 这 就 意味 着 对 端 已 经 关闭 ， 所 以 不 


可 能 再 有 新 的 数据 了 。 


才 

if (sock flag(sk, SOCK DONE)) 
break; 

/* 判断 套 接 字 是 否 出 错 


if (sk->sk err) { 
copied = sock error(sk); 
break; 
} 
/* 套 接 字 关闭 了 接收 端 
wy 


if (sk->sk shutdown & RCV_SHUTDOWN) 
break; 
/* 套 接 字 状 态 为 关闭 状态 但 又 没有 设置 


SOCK_DONE 标 志 ， 这 种 情况 只 发 生 在 用 户 企图 从 一 个 未 连接 的 套 接 字 中 读 取 数据 时 。 


wy 
if (sk->sk state == TCP CLOSE) { 


if (!sock flag(sk, SOCK DONE)) { 
copied = -ENOTCONN; 
break; 

} 

break; 


/* 已 经 超时 


if (ltimeo) { 
copied = -EAGAIN; 
break; 
} 
/* 有 未 处 理 的 信号 
Ed 
if (signal pending(current)) { 
Copied = sock intr errno(timeo); 
break; 
} 
下 
/* 清除 已 经 读 取 的 数据 包 
Wid 
tcp cleanup rbuf (sk, copied); 
/* 要 进行 低 延 时 的 
了 TCP 处 理 
*/ 
if (!sysct1 tcp low latency && tp->ucopy.task == user recv) { 
/* 保存 用 户 进程 地 址 


if (!user recv && ! (flags & (MSG TRUNC | MSG PEEK))) { 
user recv = current; 
tp->ucopy.task = user recv; 
tp->ucopy.iov = msg->msg iov; 
} 
tp->ucopy.len = len; 
WARN_ ON (tp->copied seq != tp->rcv nxt && 
!(flags & (MSG PEEK | MSG TRUNC))); 
/* 
处 理 完 


receive queue,， 需要 处 理 


prequeue . 


TCP 套 接 字 有 三 个 队列 ， 需 要 按照 以 下 顺序 来 处 理 : 


receive queue; 


2 
Prequeue: 

3) 
backlog: 

*A 


if (!skb queue empty (&tp->ucopy.prequeue)) 
goto do prequeue; 
/* _ Set realtime policy in scheduler _*/ 


} 
#ifdef CONFIG NET DMA 
if (tp->ucopy.dma chan) { 
if (tp->rcv wnd == 0 && 
!skb queue empty(&sk->sk async wait queue)) { 
/* 
接收 窗口 已 经 为 


0， 并 且 有 进程 正在 等 待 数据 ， 这 时 就 要 尽快 接收 数据 。 所 以 这 里 的 


dma 操作 为 同步 的 。 


i 
tecp_ service net dmal(sk, true); 
tcp cleanup rbuf (sk, copied); 
} else 
Gma async memcpy issue pending (tp->ucopy.dma chan); 


#endif 
if (copied >= target) { 
/* 车 已 经 复制 了 超过 目标 的 数据 量 ， 则 释放 该 套 接 字 


a 
release sock (sk); 
lock sock(sk); 
} else { 
/* 等 待 更 多 的 数据 


二 
sk wait_data(sSk，&timeo) 7 


上 
#ifdef CONFIG NET DMA 
tecp service net dmal(sk, false); /* Don't block */ 
tp->ucopy.wakeup = 0; 
#endif 
if (user recv) 1{ 
int chunk; 
/* __ Restore normal policy in scheduler _*/ 
if ((chunk = len - tp->ucopy.len) != 0) { 
NET ADD STATS USER(sock net (sk), 
LINUX MIB TCPDIRECTCOPYFROMBACKLOG, chunk); 
len -= chunk; 
copied += chunk; 


; 
/* 处 理 完 
receive_queue,， 再 继续 处 理 


prequeue */ 
if (tp->rcv nxt == tp->copied seq && 
!skb queue empty(&tp->ucopy.prequeue)) { 
do prequeue: 
tcp prequeue process (sk); 
/* 计算 从 


Prequeue 中 读 取 的 数据 长 度 ， 并 调整 相应 的 
len 和 
copied. 


* 
if ((chunk = len - tp->ucopy.len) != 0) { 
NET ADD STATS USER(sock net (sk), 
LINUX MIB TCPDIRECTCOPYFROMPREQUEUE, chunk); 
len -= chunk; 
copied += chunk; 


} 


} 

if ((flags & MSG PEEK) && 
(peek seq - copied - urg hole != tp->copied seq)) { 
if (net ratelimit()) 

Printk (KERN DEBUG “TCP (%s:%d): Application bug, race in MSG PEEK.\n", 
current->comm, task pid nr(current)); 

peek seq = tp->copied seq; 

} 

continue; 

found ok skb: 
/ Ok so how much can we use? */ 
/* 找到 了 正确 的 


Skb, 计算 该 
Skb 未 读 的 可 用 数据 长 度 


wf 
used = skb->len - offset; 


/* 如 果 用 户 要 读 取 的 长 度 小 于 当前 的 剩余 长 度 ， 则 调整 可 用 长 度 





wf 
if (len < used) 





TCP 的 紧急 数据 又 称 带 外 数据 ， 在 协议 定义 本 身 一 直 都 有 些 争议 。 所 以 其 实现 代码 也 比较 奇怪 。 一 般 


不 推荐 在 日 常 编码 中 使 用 紧急 数据 


a 
if (tp->urg data) { 
/* 得 到 紧急 数据 的 偏 移 


wy 
U32 urg offset = tp->urg seq - *seq; 
/* 判断 紧急 数据 是 否 在 我 们 要 读 取 的 数据 范围 内 
i 
if (urg offset < used) { 
if (!urg offset) { 
/* 判断 紧急 数据 是 否 在 普通 数据 流 中 
wf 


if (!sock flag(sk, SOCK URGINLINE)) { 
/* 车 不 在 普通 数据 流 中 ， 则 要 忽略 当前 这 个 字 节 


a 
++*seq; 
urg holett; 
offset+t+; 
used--; 
if (!used) 
goto skip copy; 


} else 
used = urg offset; 
} 


} 
/* 没有 设置 截断 标志 


二 六 
if (!(flags & MSG TRUNC)) { 
/* 先 尝试 使 用 


DMA 来 将 数据 复制 到 用 户 空间 


wy 
#ifdef CONFIG NET DMA 
if (!tp->ucopy.dma chan && tp->ucopy.pinned list) 
tp->ucopy.dma chan = dma find channel (DMA MEMCPY); 
if (tp->ucopy.dma chan) { 
tp->ucopy.dma cookie = dma skb copy datagram iovec( 
tp->ucopy.dma chan, skb, offset, 
msg->msg iov, used, 
tp->ucopy.pinned list); 
if (tp->ucopy.dma cookie < 0) { 
printk (KERN ALERT "dma cookie < 0\n"); 
/* Exception. Bailout! */ 
if (!copied) 
copied = -EFAULT; 
break; 
} 
dma async memcpy issue pending (tp->ucopy.dma chan); 
if ((offset + used) skb->len) 
copied early = 1 





} else 


t 


#endif 


/* 复制 数据 到 用 户 空间 


a 
err = skb copy datagram iovec(skb, offset, 
msg->msg_iov, used); 
4 (Eel 证 
/* Exception. Bailout! */ 
if (!copied) 
copied = -EFAULT; 
break; 


} 
} 
/* 调整 序列 号 


* Seq、 已 复制 长 度 、 剩 余 长 度 


.A 

*seq += used; 

copied += used; 

len -= used; 

/* 因为 成 功 读 取 了 数据 ， 所 以 要 调整 
TCP 套 接 字 的 接收 缓存 
wy 


tecp rev_ space adjust (sk); 
skip_copy: 
/* 如 果 正在 读 取 ， 并 且 已 读 取 的 序列 号 大 于 紧急 数据 ， 则 意味 着 已 经 读 取 完了 





要 重 置 


urg_data, 并 日 进 行 


了 TCP 快速 路 径 检查 如 果 通 过 了 检查 条 件 ， 则 打开 快速 路 径 开 关 。 


打开 快速 路 径 的 时 候 ， 表 示 接 收 的 数据 包 是 预期 的 数据 包 ， 


了 CP 接收 数据 包 时 会 做 比较 少 的 检 


查 ， 因 此 接收 更 为 快速 ) 


4 
if (tp->urg data && after(tp->copied seq, tp->urg seq)) { 
tp->urg data = 07 
tecp fast path check (sk); 
} 
/* 使 用 的 数据 长 度 加 上 偏 移 若 小 于 数据 包 的 长 度 ， 则 读数 据 包 可 以 继续 使 用 


if (used + offset < skb->len) 
continue; 
/* 如 果 该 数据 包 有 


了 IN 标志 ， 则 跳 转 到 


found fin ok */ 
if (tcp_hdqr (skb) ->fin) 
goto found fin ok; 
/* 如 果 没 有 设置 


MSG_PEEK 标 志 ， 则 需要 从 接收 队列 中 消耗 掉 这 个 数据 包 ， 并 根据 


copied 
eaL]Y 标 志 ， 将 其 直接 释放 ， 或 者 放置 到 异步 队列 
if (!(flags & MSG PEEK)) { 
sk eat skb(sk, skb, copied early); 
copied early = 0; 
} 
continue; 
found fin ok: 
/* 这 里 开始 处 理 
了 IN 数据 包 
i 
/* FIN 标 志 也 占用 一 个 序列 号 ， 因 此 要 给 序列 号 加 一 
wf 
++*aed; 
/* 与 前 文 相同 ， 不 再 重复 注释 
二 


if (!(flags & MSG PEEK)) { 
sk eat skbl(sk, skb, copied early); 
copied early = 0; 


上 
/* 接收 到 


了 IN 标志 ， 表 示 对 端 已 经 关闭 了 写 通道 ， 那 么 对 于 本 端 米 说 ， 这 是 最 后 一 个 可 读数 据 包 ， 


因此 退出 循环 


*/ 
break; 
} while (len > 0); 
if (user recv) { 
/* prequeue 队 列 中 仍然 





取 的 数据 包 


Ww 
if (!skb queue empty(&tp->ucopy.prequeue)) { 
int chunk; 
/* 设置 要 读 取 的 长 度 
*¥ 
tp->ucopy.len = copied > 0 ? len : 0; 
/* 处 理 
prequeue 队 列 
二 


tcp prequeue process (sk); 

if (copied > 0 && (chunk = len - tp->ucopy.len) != 0) 
NET ADD STATS USER(sock net (sk), LINUX MIB TCPDIRECTCOPYFROMPREQUEUE, chunk); 
len chunk; 
copied += chunk; 





} 
} 
tp->ucopy.task = NULL; 
tp->ucopy.len = 0; 


} 
#ifdef CONFIG NET DMA 
tcp service net dmal(sk, true); /* Wait for queue to drain */ 
tp->ucopy.dma chan = NULL; 
if (tp->ucopy.pinned list) { 
dma unpin iovec pages (tp->ucopy.pinned list); 
tp->ucopy.pinned list = NULL; 


上 
#endif 
/* 释放 已 经 读 取 的 数据 包 


Wy 
tcp cleanup rbuf (sk, copied); 
/* 释放 套 接 字 控 制 权 


i 
release sock (sk); 
return copied; 
out: 
release sock (sk); 
return err; 
recv_urg: 
/* 接收 紧急 数据 


本 


err = tcp recv urgl(sk, msg, len, flags); 
goto out; 








而 的 tcp_recvmsg 已 经 加 了 大 量 的 注释 ， 但 是 




















于 这 个 函数 的 逻辑 过 于 复杂 ， 再 加 上 TCP 接 收 队列 的 多 样 性 ， 即 使 已 经 看 完了 这 个 函数 的 实现 ， 却 仍然 无 法 清楚 地 掌握 它 的 整体 脉络 。 接 下 来 ， 我 们 





14.$ ”TCP 套 接 字 的 三 个 接收 队列 








在 Linux 内 核 中 ， 除 了 错误 队列 外 ，TCP 套 接 字 一 共有 三 个 接收 队列 。 它 们 分 别 是 struct sock 中 的 
sk_receive_queue 和 sk_backlog， 以 及 struct tcp_sock 中 的 prequeue。 先 简单 介绍 一 下 它们 各 自 的 用 途 ， 然 
后 再 看 具体 的 代码 实现 。sk_receive_queue 是 真正 的 接收 队列 ， 收 到 的 TCP 数 据 包 经 过 检查 和 处 理 后 ， 
就 会 保存 在 这 个 队列 中 ， 用 户 态 也 是 从 这 里 读 取 数 据 的 。sk_backlog 是 socket 正 处 于 用 户 进程 上 下 文 
( 即 用 户 正在 对 socket 进 行 系统 调用 ， 如 recv) ， 当 Linux 内 核 收 到 数据 包 时 ， 在 软 中 断 的 处 理 过 程 中 ， 
内 核 会 将 数据 包 保 存在 sk_ backlog 中 ， 然 后 直接 返回 。 而 prequeue 则 是 在 该 socket 没 有 正在 被 用 户 进 程 使 
用 时 ， 由 软 中 断 直接 将 数据 包 保 存在 prequeue 中 ， 并 返回 。 从 上 面 的 说 明 可 以 看 出 ， 对 于 TCP 套 接 字 ， 
它 不 管用 户 态 是 否 正在 使 用 套 接 字 ， 都 不 做 真正 的 处 理 ， 而 是 把 数据 包 保 存在 队列 中 ， 这 是 为 什么 
有 呢 ? 这 是 因为 TCP 协 议 相 对 复杂 ， 内 核 为 了 尽快 让 软 中 断 结 束 ， 就 不 进行 多 余 的 处 理 了 ， 尽 量 在 用 户 进 
程 上 下 文中 处 理 数据 包 。 下 面 来 看 看 TCP 相 关 的 源 代码 。 



































首先 ， 人 查看 TCP 的 接收 处 理 函 数 tcp_v4_rev 中 的 一 部 分 代码 : 








bh Loek sock nested (sk); 

ret = 

if (sosk owned by user(sk)) { 
/* 用 户 态 没有 正在 使 用 这 个 套 接 字 





























大 
/ 
#ifdef CONFIG NET DMA 
struct 七 cp sock *tp = tcp sk(sk); 
if (!tp->ucopy.dma chan && tp->ucopy.pinned list) 
tp->ucopy.dma chan = dma find channel (DMA MEMCPY); 
if (tp->ucopy.dma chan) 
ret = tcp v4 do rcv(sk, skb); 
else 
#endif 


/* 先 尝试 保存 到 





Prequeue 中 ， 若 失败 的 话 再 进入 


了 CBE 真正 的 处 理 函数 中 





4 
if (!tcp prequeue (sk, skb)) 
ret = 七 gp v4 do rcvl(sk, skb); 


} 
/* 车 该 套 接 字 正在 被 用 户 态 使 用 ， 则 将 数据 包 保存 到 
Dack1og 中 。 如 果 失 败 的 话 ， 就 丢弃 这 个 包 。 


类 
} else if (unlikely(sk aqq backlog(sk, skb))) { 
bh unlock sock (sk); 
NET INC STATS BH (net, LINUX MIB TCPBACKLOGDROP); 
goto discard . and relse; 


} 
bh unlock sock (sk); 





然后 进入 tcp_prequeue， 看 看 什么 时 候 会 返回 失败 ， 代 码 如 下 : 





static inline int tcp prequeue (Struct sock *sk, struct sk buff *skb) 
{ 

struct tcp sock *tp = tcp sk(sk); 

/* 配置 了 低 延 时 








TCP， 或 者 该 套 接 字 没有 对 应 的 用 户 态 进程 ， 返 回 失败 。 让 内 核 直接 处 理 














了 TCP 数据 包 。 


*/ 
if (sysctl tcp low latency || !tp->ucopy.task) 
return 0; 
/* 将 数据 包 追 加 到 








Prequeue 队 列 中 ， 并 增加 相应 的 内 存 统 计 。 


娄 

skb queue tail(&tp->ucopy.prequeue, skb); 
tp->ucopy.memory += skb->truesize; 
if (tp->ucopy.memory > sk->sk rcvbuf) { 

/* 当 超 过 了 套 接 字 指 定 的 接收 缓存 大 小 时 


*/ 
struct sk buff *skbl; 
BUG ON(sock owned by user (sk)); 
/* 将 数据 包 从 








Prequeue 中 转移 到 





backlog 中 


大 
/ 
while ((skbl = skb dequeue(&tp->ucopy.prequeue)) != NULL) { 
Sk backlog rcv(sk, skbl1); 
NET INC STATS BH(sock net (sk), 
LINUX MIB TCPPREQUEUEDROPPED); 
} 


tp->ucopy.memory = 0; 
} else :if (skb queue len(&tp->ucopy.prequeue) == 1) { 
/* 如 果 该 数据 包 是 




















Prequeue 中 的 第 一 个 数据 包 ， 则 唤醒 在 该 套 接 字 中 等 待 接收 的 进程 





WA 
wake up interruptible sync polll(sk sleep (sk), 
POLLIN | POLLRDNORM | POLLRDBAND); 
/* 如 果 


aCk 定 时 器 没有 被 调度 ， 则 设置 


ck 定时 器 


4 
if (!inet csk ack scheduled (sk)) 
inet csk reset xmit timer(sk, ICSK TIME DACK， 
(3 * tcp rto min(sk)) / 4, 
TCP_ RTO MAX); 





} 


return 1; 


} 


然后 查看 sk add_backlog， 代 码 如 下 : 





static inline must check int sk add backlog (struct sock *sk, struct sk buff *skb) 


/* 接收 队列 已 满 ， 则 返回 








ENOBUFS 错 误 。 所 谓 的 接收 队列 已 满 ， 即 接收 缓存 的 数据 包 占 用 的 内 存 超过 了 限制 。 











4 
if (sk rcvqueues full (sk, skb)) 
return -ENOBUFS; 
/* 将 数据 包 追 加 到 


ljbacklog 队 列 中 ， 并 增加 相应 的 内 存 统计 。 





*/ 
__ Sk add backlog(sk, skb); 
Sk->sk backlog.len += skb->truesize; 
return 0; 


} 


看 完 这 些 代 码 后 ， 我 们 应 该 产生 一 个 疑问 。 既 然 prequeue 和 backlog 都 是 保存 的 未 经 处 理 的 TCP 数 据 
包 ， 那 么 为 什么 还 需要 两 个 不 同 的 队列 呢 ? 为 了 解答 这 个 疑问 ， 就 需要 研究 内 核 是 如 何 使 用 这 两 个 队 
列 的 了 。 前 面 的 代码 是 这 两 个 队列 的 写 入 操作 ， 接 下 来 我 们 看 一 下 这 两 个 队列 是 何 时 被 读 取 的 。 


























prequeue 队 列 的 处 理 函 数 是 tcp_prequeue process， 它 是 在 TCP 的 读 取 数据 函数 tcp_recvmsg 中 被 调用 
的 。 在 tcp_recvmsg 的 入 口 ， 内 核 会 调用 lock_sock 来 设置 sk->sk lockowned， 表 示 该 套 接 字 由 用 户 进程 所 
占有 ， 然 后 会 对 receive_queue 和 prequeue 中 的 数据 包 进 行 处 理 。 正 因为 sock 被 用 户 进程 占用 时 ， 会 访问 
prequeue 队 列 ， 所 以 为 了 避免 竞争 ， 软 中 断 在 收 到 数据 包 时 就 只 能 把 数据 包 保存 到 backlog 中 。 那 么 为 什 
么 当 sock 不 被 用 户 进程 占用 时 ， 软 中 断 不 将 数据 包 保存 到 backlog 中 ， 而 是 保存 到 prequeue 中 呢 ? 














要 回答 这 个 问题 ， 还 是 要 继续 查看 backlog 是 何 时 被 读 取 的 。 让 人 觉得 有 点 出 乎 意料 的 是 ，backlog 
的 数据 包 居 然 是 在 ”release_sock 中 被 处 理 的 。 





static void release sock (Struct sock *sk) 
__releases(&sk->sk lock.slock) 
__ acquires(&sk->sk lock.slock) 


struct sk buff *skb = sk->sk backlog.head; 
/* 处 理 


ljbacklog 队 列 的 数据 包 


#7/ 
do { 
Sk->sk backlog.head = sk->sk backlog.tail = NULL; 
bh unlock sock (sk); 
do { 
struct sk buff *next = skb->next; 
WARN ON ONCE (skb dst is noref (skb)); 
skb->next = NULL; 
sk backlog rcv (sk， skb); 
Ph 
* We are in process context here with softirgs 
* disabled, use cond resched softirqg() to preempt. 
* This is safe to do because we've taken the backlog 
* queue private: 
*/ 





cond resched softirqg(); 
skb = next; 
} while (skb != NULL); 
bh lock sock (sk); 
} while ((skb = sk->sk . backlog.head) != NULL); 
/ 
* Doing the zeroing here guarantee we can not loop forever 
* while a wild producer attempts to flood us. 
类 


Sk->sk backlog.len = 0; 





不 过 这 也 解释 了 对 于 TCP 套 接 字 ， 为 什么 需要 两 个 队列 来 保存 未 处 理 的 数据 包 。 


对 于 套 接 字 的 使 用 情况 ， 一 共有 两 个 状态 : 








:用 户 进 程 正在 占用 该 套 接 字 。 





:用 户 进 程 未 占用 该 套 接 字 。 








而 内 核 在 任何 情况 下 ， 都 要 尽量 保证 尽快 返回 软 中 断 ， 以 避免 资源 竞争 。 因 此 ， 在 套 接 字 的 这 两 
个 状态 下 ， 都 要 保证 软 中 断 可 以 毫 无 阻塞 地 将 数据 包 保 存 到 未 处 理 队 列 中 ， 自 然 也 就 需要 两 个 队列 
了 。 当 用 户 进程 正在 占用 套 接 字 时 ， 其 会 访问 prequeue， 那 么 软 中 断 就 将 数据 包 保 存 到 backlog 中 。 当 用 

户 放弃 对 套 接 字 的 占用 时 ， 其 会 访问 backlog， 而 这 时 ， 软 中 断 就 会 将 数据 包 保 存 到 prequeue 中 。 


























14.6 从 网 卡 到 套 接 字 


对 于 一 般 的 套 接 字 编 程 来 说 ， 大 多 是 应 用 编程 ， 所 以 基本 上 都 是 UDP 或 TCP 协 议 的 套 接 字 。 前 面 两 
章 是 从 应 用 层次 的 角度 ， 自 上 而 下 地 分 析 了 UDP 和 TCP 数 据 包 的 发 送 和 接收 流程 。 但 同时 也 有 了 一 个 新 
的 问题 ， 数 据 包 是 如 何 进 入 对 应 套 接 字 的 接收 缓冲 区 的 呢 ? 本 章 将 从 网 卡 接收 到 数据 包 开 始 ， 一 直 跟 
踊 到 内 核 将 数据 包 放 入 到 对 应 的 套 接 字 绥 冲 区 中 为 止 。 














14.6.1 ”从 硬 中 断 到 软 中 晰 


对 于 网 卡 来 说 ， 数 据 包 的 到 达 是 一 个 无 法 预料 的 事件 ， 系 统 需要 通过 某 种 手段 来 得 知 该 事件 。 一 
般 来 说 ， 有 两 种 方式 : 轮 询 和 中 断 。 用 直 白 的 语言 来 描述 ， 轮 询 就 是 CPU 不 断 地 问 网 卡 :“ 你 那 有 准备 
好 的 数据 包 吗 ? ”如 果 网 卡 回答 有 数据 包 的 话 ，CPU 就 进行 处 理 ， 不 然 要 么 干 点 别 的 ， 要 么 继续 问 。 中 
断 则 是 没有 数据 包 时 ，CPU 该 干 嘛 干 嘛 ， 符 网 卡 收 到 数据 包 ， 就 直接 喊话 “ 喂 ， 有 活 干 了 ”"。 于 是 CPU 赶 
紧 把 手头 的 工作 保存 一 下 ， 并 尽快 响应 任务 。 第 一 种 方式 ， 毫 无 疑问 会 造成 CPU 的 浪费 。 因 为 在 网 卡 
没有 数据 包 的 时 候 ，CPU 还 要 浪费 计算 周期 来 询问 网 卡 。 第 三 种 中 断 方式 看 上 去 很 美 ， 网 卡 没有 数据 
的 时 候 ，CPU 可 以 做 其 他 的 事情 ; 有 数据 的 时 候 ， 就 可 以 及 时 处 理 。 然 而 在 实际 应 用 中 ， 中 断 方式 也 
有 很 大 的 问题 。 在 CPU 响应 中 断 时 ， 为 了 不 影响 当前 的 工作 ， 需 要 将 当前 工作 的 上 下 文保 存 起 来 ， 然 
后 再 进行 中 断 处 理 。 试 想 ， 当 前 千 光 、 万 兆 网 卡 已 经 非常 普遍 ， 若 是 那 时 网 卡 满 负 载 ， 那 么 每 秒 钟 就 
会 产生 大 量 的 中 断 。 除 了 切换 过 程 带 来 的 计算 代价 ， 上 下 文 的 切换 还 会 导致 CPU Cache 的 失效 一 一 这 对 
高 性 能 设备 来 说 ， 是 一 个 不 可 忽视 的 问题 。 于 是 ，Linux 对 这 两 种 方式 进行 了 折 中 ， 引 入 了 一 个 New 
API， 缩 写 为 NAPI。 简 单 来 说 ， 在 CPU 响应 网 卡 中 断 时 ， 不 再 仅仅 是 处 理 一 个 数据 包 就 退出 ， 而 是 使 用 
轮 询 的 方式 继续 尝试 处 理 新 数据 包 ， 直 到 没有 新 数据 包 到 来 ， 或 者 达到 设置 的 一 次 中 断 最 多 处 理 的 数 
据 包 个 数 。 这 个 NAPI 同 时 兼 有 了 轮 询 和 中 断 两 种 方式 的 特点 。 













































































网 卡 硬 中 断 的 处 理 是 在 网 卡 驱动 中 进行 的 ， 这 个 与 硬件 的 联系 过 于 紧密 ， 我 们 可 以 忽略 细节 。 只 
需要 知道 对 于 支持 NAPI 的 网 卡 来 说 ， 其 读 取 数据 包 的 硬 中 断 处 理 函 数 会 调用 ”napi_schedule 将 网 卡 加 
入 NAPI 的 poll list 中 ， 代 码 如 下 : 











void napi schedule(struct napi struct *n) 
{ 

unsigned long flags; 

/* 禁止 本 地 中 断 ， 保 护 添加 


Poll 14ist 的 临界 区 


local irqg save (flags); 
/* 加 入 到 当前 


CPU 的 


Poll1 列 表 中 


六 
napi schedule(& get cpu var (softnet data), n); 
local irg restore (flags); 


} 





进入 ”napi _ schedule， 代码 如 下 : 





static inline void napi _ schedule (struct softnet data *sd, 
struct napi struct *napi) 





/* 将 


napi 加 入 队 尾 


4 
list adqd tail(&napi->poll list, &sd->poll list); 
/* 触发 当前 


CPU 接收 软 中 断 〈 实 际 上 是 设置 一 个 标志 位 





4 
} 


raise softirqgq irqoff (NET RX SOFTIRO); 








关于 中 断 处 理 为 什么 要 分 为 硬 中 断 和 软 中 断 〈 也 经 常 被 称 为 上 下 部 分 ) 的 解释 已 经 很 多 了 。 简 单 
地 说 : 硬 中 断 处 理 是 一 个 特殊 的 上 下 文 ，CPU 会 屏蔽 掉 绝 大 部 分 中 断 ， 并 且 有 不 少 的 限制 。 所 以 硬 中 
断 应 尽 可 能 快 地 处 理 ， 以 提高 系统 的 响应 速度 ， 因 此 内 核 将 具体 的 处 理工 作 放 到 了 软 中 断 中 。 











14.6.2” 软 中 断 处 理 
14.6.1 节 中 ， 我 们 看 到 硬 中 断 通过 设置 标志 位 “触发 "了 软 中 断 。 那 么 内 核 又 是 何 时 处 理 软 中 断 的 呢 ? 
了 前 要 处 理 软 中 晰 : 


Ti 























目前 ， 在 以 下 几 种 条 件 下 ， 内 核 会 检查 是 否 


:退出 硬 中 断 上 下 文 时 。 





EE 新 enable 软 中 断 时 。 
每 个 CPU 都 有 一 个 ksoftirqd 的 内 核 线 程 。 当 内 核 的 软 中 断 数量 过 多 时 ， 就 会 唤醒 该 线程 循环 处 理 软 中 


1 四 





接收 数据 包 的 软 中 断 处 理 函 数 为 net rx_action， 人 代码 如 下 : 





static void net rx _ action (struct softirq action *h) 


{ 
/* 接收 数据 包 的 
Per CPU 队 殉 


yy 
struct softnet data *sd = & get cpu var(softnet data); 


/* 最 长 的 运行 时 间 限 制 为 


2 六 


jiffies */ 
unsigned long time limit = jiffies + 2; 


/* 
一 次 软 中 断 最 多 处 理 的 包 个 数 。 


netdev_ budget 的 值 为 


/proc/sys/net/core/netdev budget 
党 
netdev budget; 


int budget 
void *have; 
/* 因为 网 卡 驱动 会 访问 


Poll Is 七 ， 因 此 需要 禁止 本 地 硬 中 断 以 进行 保护 


local irq disable(); 


/* 遍历 加 入 到 


Jpol 1 链表 的 所 有 网 卡 


大 
/ 
while (!list empty(&sd->poll list)) { 
struct napi struct *n; 
int work, weight; 
/* 如 果 已 经 处 理 完了 允许 的 最 大 包 个 数 ， 或 超出 了 允许 的 时 间 限制 ， 则 退出 此 次 处 理 


wf 
if (unlikely (budget <= 0 || time after (jiffies, time limit))) { 
/* 这 时 退出 此 次 收 包 软 中 断 只 是 为 了 避免 过 长 时 间 地 占 














CPU， 所 以 跳 到 


softnet lbbreak, 再 触发 一 次 收 包 软 中 断 ， 以 便 下 次 继续 处 理 


*/ 
goto softnet break; 
} 
/* 打开 本 地 硬 中 断 





本/ 
local irg enable(); 
/* 这 里 在 打开 硬 中 断 时 ， 虽 然 访问 了 





Poll 1ist, 但 仍然 是 安全 的 。 因 为 硬 中 断 只 是 在 往 


Poll 1i st 的 末尾 插入 ， 并 不 会 影响 第 一 个 元 素 。 





A 
n= list first entry(&sd->poll list, struct napi struct; Boll Jist)? 
/* 获得 该 设备 的 
DetPol1 锁 
have = netpoll poll lock (n) 
/* 得 到 该 网 卡 的 权重 ， 其 意义 一 般 为 在 这 个 网 卡 上 接收 几 个 数据 包 
A 


weight = n->weight; 
/* This NAPI STATE SCHED test is for avoiding a race 
* with netpoll's poll napi(). Only the entity which 
* obtains the lock and sees NAPI STATE SCHED set will 
* actually make the ->poll() call. Therefore we avoid 
* accidentally calling ->poll() when NAPI is not scheduled. 
大 
/ 
work = 0; 
/* 再 次 检查 该 网 卡 是 否 有 





NAPI 调 用 (因为 与 














netpoll 有 竞争 ) 


if (test bit (NAPI STATE SCHED, &n->state)) { 
/* 对 网 卡 进行 查询 操作 ， 


WOIK 值 为 读 取 的 数据 包 个 数 


*/ 
work = n->poll (n, weight); 
trace napi poll (n); 
} 
WARN ON ONCE (work > weight); 
/* 更 新 包 预 算 即 目前 还 可 以 读 取 的 数据 包 个 数 


4 

budget -= work; 

local irg disable(); 

/* 判断 从 该 网 卡 读 取 的 数据 包 是 否 达到 预算 个 数 
2 


if (unlikely(work == weight)) { 
/* 判断 该 网 卡 的 


NAPI 是 否 被 禁止 了 


人 
if (unlikely(napi disable pending(n))) { 
/* 车 


NAPI 已 经 被 禁止 了 ， 则 执行 


NAPI 的 完成 处 理 


5 
local irq _ enable () ， 
napi complete(n); 
local irgq disable(); 
} else { 
/* 若 该 设备 仍 要 继续 进行 


NAPI 操 作 ， 则 将 其 移 至 队 尾 


人 
list move tail(&n->poll list, &sd->poll list); 
} 
} 
/* 释放 
netpoll 锁 
把: 
netpoll poll unlock (have) 
} 
out: 


/* 执行 


RPS 处 理 并 打开 本 地 硬 中 断 


net rps action and irg enable(sd); 
#ifdef CONFIG NET DMA 
/* 启动 未 处 理 的 





DMA 操 作 


大 
/ 
dma issue pending all(); 
#endif 可 本 
return; 
softnet break: 
/* 本 次 没有 接收 完 所 有 的 数据 包 ， 再 触发 一 次 软 中 断 


*/ 
sd->time squeezett+; 
raise softirq irqoff (NET RX SOFTIRQ) ， 
goto out; 





} 














在 这 个 收 包 软 中 断 处 理 函 数 中 ，CPU 会 毅 历 poll 列 表 ， 调 用 挂 载 到 NAPI 列 表 上 的 网 卡 回 调 函 数 poll， 
来 轮 询 接收 数据 包 。 所 以 ， 我 们 还 需要 通过 驱动 代码 ， 来 跟踪 收 包 流 程 。 在 此 ， 以 Intel 的 e1000 网 卡 驱 动 
为 例 来 进行 讲解 ， 在 使 用 NAPI 的 情况 下 ， 其 收 包 流 程 为 


net rx action—>e1000 clean—>e1000 clean rx lirq 一 el1000 receive skb—>napi gro receive—netif receive _Skb。 





























在 这 个 调用 链 上 ， 有 一 个 函数 napi_gro_receive， 其 用 来 支持 GRO (Generic Receive Offload) 。 这 个 GRO 则 
是 用 于 减轻 CPU 的 处 理 压力 的 。 大 家 可 以 计算 一 下 ， 对 于 10GB、100GB 的 网 卡 来 说 ， 即 使 每 个 数据 包 都 是 
1500 字 节 〈 以 太 网 的 最 大 MTU， 和 暂 不 考虑 Jumbo 帧 ) ， 那 么 每 秒 钟 系统 需要 处 理 多 少 个 数据 包 ? 因 此， 为 
了 减轻 CPU 的 负担 ，Linux 内 核 在 驱动 层 引 入 了 GRO， 它 会 将 符合 条 件 的 数据 包 合并 为 一 个 数据 包 再 传递 给 
系统 协议 栈 。 在 此 ， 我 们 只 关注 数据 包 的 接收 流程 ， 就 不 研究 GRO 的 实现 了 。 有 兴趣 的 读者 可 以 自行 阅读 
源 代码 。 




















14.6.3 ”传递 给 协议 栈 流程 





数据 包 在 脱离 驱动 层 后 ， 就 进入 了 netif receive_skb， 代 码 如 下 : 





int netif receive skbl(struct sk buff *skb) 


/* 判断 是 否 在 入 队 前 给 数据 包 打 时 间 截 


大 
/ 
if (netdev tstamp prequeue) 
net timestamp check (skb); 
if (skb defer rx timestamp (skb)) 
return NET RX SUCCESS; 
/* 是 否 打 开 了 





RPS* 





Receive Packet Steering) 编译 开关 ， 其 根据 数据 包 的 


工地 址 和 端口 号 进 


hash 运 算 ， 将 其 发 送 给 对 应 的 


CPU。 这样， 一 方面 保证 了 


CPU 间 的 负载 均衡 ， 另 一 方面 将 同一 特征 


的 数据 包 发 给 相同 的 


CPU， 可 以 提高 





Cache 的 命中 率 。 


7 
#ifdef CONFIG RPS 
{ 
struct rps dev flow voidflow, *rflow = &voidflow; 
int cpu, ret; 
rcu read lock(); 
/* 根据 


RPS 算 法 ， 计 算得 到 处 理 这 个 数据 包 的 


CPU */ 
cpu = get rps cpul(skb->dev, skb, &rflow); 
XS 曙 


CPU 大 于 等 于 
0 时 ， 表 示 


RPS 计 算得 到 了 正确 的 








CPU 的 接收 队列 追加 这 个 数据 包 











*/ 
ret = enqueue to backlog(skb, cpu, &rflow->last qtail); 
rcu read unlock(); 
} else { 
/* 由 本 
CPU 处 理 该 数据 包 
二 
rcu read unlock(); 
ret = netif receive skb (skb); 
} 
Eetorn ety 
} 
#else 
/* 本 
CPU 继续 处 理 该 数据 包 
*/ 
return netif receive skb (skb); 
#endif 


} 








这 里 可 以 看 出 netif receive_skb 只 是 对 ”netif receive_skb 的 封装 ， 增 加 了 对 RPS 的 支持 。 继 续 跟 进 
_ netif receive_skb， 代 码 如 下 : 





static int netif receive skbl(struct sk buff *skb) 


{ 





struct packet type *ptype, *pt prev; 

rx handler func t *rx handler; 

struct net device *orig dev; 

struct net device *null or dev; 

bool deliver exact = false; 

int ret = NET RX DROP; 

_ pe16 type; 

/* 如 果 没 有 打开 入 队 前 采样 数据 包 的 时 间 惟 功能， 则 需要 在 这 里 进行 数据 包 时 间 戳 采样 











大 
/ 
if (!Inetdev tstamp prequeue) 
net timestamp check (skb); 
trace netif receive skb (skb); 
/* 判断 是 否 





netpoll1 处 理 


96 

if (netpoll receive skb (skb)) 
return NET RX DROP; 

/* 设置 网 卡 的 入 口 网 1 








tr 


4 
if (!skb->skb iif) 
Skb->skb iif = skb->dev->ifindex; 
orig dev = skb->dev; 
/* 初始 化 数据 包 的 网 络 层 首部 、 传 输 层 首部 ， 以 及 二 层 














MAC 首 部 的 长 度 


大 
/ 
skb reset network header (skb); 
skb reset transport header (skb); 
skb reset mac len (skb); 
pt _prev = NULL; 
rcu read lock(); 
another round: 
__this cpu inc(softnet data.processed); 
/* 如 果 是 





802 .1Q 协 议 的 数据 包 


A 
if (skb->protocol == cpu to bel6 (ETH P 80210)) { 
/* 则 去 掉 





vlan tag */ 
Skb = vlan untag (skb); 
if (unlikely(!skb)) 
goto out; 


} 
/* 内 核 打开 了 包 分 类 编译 选项 


Ry 
#ifdef CONFIG NET CLS ACT 
/* 如 果 数 据 包 被 设置 了 流 控 结果 ， 则 跳 过 后 面 的 流 控 处 理 





六 
if (skb->tc verd & TC NCLS) { 
skb->tc verd = CLR TC NCLS (skb->tc verd); 
goto nels? 
} 
#endif 
/* 遍历 注册 在 


Ptype_all 上 的 所 有 节点 。 


ptype_all 上 的 节点 需要 处 理 收 到 的 所 有 以 太 网 数据 包 


6 
list for each entry rcul(ptype, &ptype all, list) { 
/* 如 果 注 册 节 点 没有 绑 定 网 卡 ， 或 者 绑 定 的 网 卡 与 数据 包 接收 的 网 卡 相同 ， 则 这 个 节点 符合 接收 数据 包 的 条 件 





*/ 
if (!Iptype->dev || ptype->dev == skb->dev) { 
/* 将 数据 包 传递 给 对 应 的 处 理 函 数 


4 
if (pt prev) 
ret = deliver skb(skb, pt prev, orig dev); 


pt prev = ptype; 


} 
/* 内 核 打开 了 包 分 类 编译 选项 


大 
/ 
#ifdef CONFIG NET CLS ACT 
skb = handle ing(skb, &pt prev, &ret, orig dev); 
if (!skb) 
goto out; 





ncls: 
#endif 
/* ”如果 这 个 数据 包 带 有 


Van 标签 


4 
if (vlan tx tag Present (skb)) { 
if (pt prev) { 
/* 则 将 数据 包 传递 给 之 前 确定 的 上 层 协议 





要 水 
ret = deliver skb(skb, pt prev, orig dev); 
pt prev = NULL; 

} 
/* 进行 
Vlan 的 处 理 
0 
if (vlan do receive(&skb)) 
goto another roungd; 
else if (unlikely(!skb)) 
goto out; 
} 
/* 


判断 该 设备 是 否 注册 了 接收 处 理 函 数 。 


设备 上 何 时 会 注册 接收 处 理 函 数 呢 ? 


netdev_rx handler register 是 注册 设备 接收 处 理 函数 的 接 


口 。 通 过 搜索 














netdev_rx handler registez 的 调用 者 ， 可 以 发 现 当 网 卡 作 为 





Dond 加 入 桥接 ， 或 者 


创建 














macvlan 了 时 ， 会 注册 网 卡 的 处 理 函数 。 使 用 这 种 方式 ， 就 做 到 了 网 卡 接收 处 理 函数 与 接收 框架 的 解 






































看 。 对 于 框架 来 说 ， 通 过 这 个 回调 函数 (用 函数 指针 实现 的 ， 内 核 中 充斥 着 这 样 的 代码 ) ， 可 以 完全 不 用 





























了 解 具体 的 细节 。 未 来 增加 更 多 的 网 卡 处 理 函数 时 ， 只 需要 在 该 具体 实现 上 ， 调 用 注册 函数 ， 而 不 用 更 改 


接收 框架 的 代码 。 


大 
/ 
rx handler = rcu dereference (skb->dev->rx handler); 
if (rx handler) { 
if (pt prev) { 
/* 将 数据 包 传递 给 之 前 确定 的 上 层 协议 








#/ 
ret = deliver skb(skb, pt prev, orig dev); 
pt prev = NULL; 

















/* 调用 在 设备 上 注册 的 处 理 函数 





* 
Switch (rx handler (&skb)) { 
case RX HANDLER CONSUMED: 
/* 处 理 函 数 已 经 消耗 了 这 个 数据 包 ， 直 接 跳 至 退出 








大 
/ 
ret = NET RX SUCCESS; 
gqoto. Hut 
Case RX HANDLER ANOTHER: 
/* 跳 至 











another_round， 即 跳 至 函数 开头 ， 重 新 处 理 


goto another roung; 
case RX HANDLER EXACT: 














/* 指示 必须 严格 匹配 接收 网 卡 











*/ 
deliver éxact = truée; 
case RX HANDLER PASS: 
/* 继续 后 面 的 处 理 
*#/ 
break; 
default: 
BUG (); 


} 


} 
/* 如 果 数 据 包 还 带 有 


Vlan tag， 则 证 明 该 数据 包 是 发 给 其 他 终端 的 





大 
/ 
if (vlan tx nonzero tag present (skb)) 
skb->pkt type = PACKET OTHERHOST; 
/* deliver only exact match when indicated */ 
null or dev = deliver exact ? skb->dev : NULL; 
/* 根据 数据 包 的 类 型 ， 遍 历 对 应 的 处 理 函 数 








大 
/ 
type = skb->protocol; 
list for each entry rcul(ptype, 
&ptype pase [ntohs (type) & PTYPE HASH MASK], list) { 
/* 如 果 数 据 包 类 型 匹配 ， 并 且 接 收 接口 设备 也 匹配 ， 则 证 明 这 是 正确 的 协议 处 理 函 数 。 然 后 调用 前 面 的 响应 处 理 函 数 ， 将 数据 包 传递 给 上 层 协议 
































大 
/ 
if (ptype->type == type && 
(ptype->dev == null or dev || ptype->dev == skb->dev || 
ptype->dev == orig dev)) { 
if (pt prev) 
ret = deliver skb(skb, pt prev, orig dev); 
pt prev = ptype; 
} 
/* 最 后 检查 








Pt_ prev 是 否 为 真 。 若 为 真 ， 则 表示 前 面 有 匹配 的 处 理 函 数 ， 然 后 进行 调用 。 如 果 为 假 ， 则 











表示 对 于 这 个 数据 包 ， 内 核 没 有 对 应 的 处 理 函 数 ， 那 就 直接 释放 这 个 数据 包 。 


#/ 
if (pt prev) { 
ret = pt prev->func(skb, skb->dev, pt prev, orig dev); 
} else { 
atomic long inc(&skb->dev->rx dropped); 
kfree skb (skb); 
/* Jamal, now you will not able to escape explaining 
* me how you were going to use this. :-) 
*/ 
ret = NET RX DROP; 





} 

out: 
rcu read unlock(); 
EEtUEN. Fety 





14.6.4 ”了 协议 处 理 流 程 





以 IPv4 的 协议 栈 处 理 为 例 进行 讲解 ， 首 先 来 看 看 IPv4 协 议 是 如 何 注 册 处 理 回调 函数 的 。 在 inet_init 
中 ， 调 用 了 dev_add_pack〈&ip_packet type) 进行 了 IPv4 协 议 的 注册 。ip_packet_type 的 定义 为 : 








static struct packet type ip packet type read mostly = { 
.type = cpu to bel6(ETH P IP), 
.func = ip rev, 
.gso_send_check = inet gso send check, 
.gso segment = inet gso segment， 
.gro receive = inet gro receive, 
.gro complete = inet gro complete, 




















因此 ，ip_rcv 为 IPv4 协 议 数据 包 的 入 口 函 数 。 下 面 来 看 看 该 函数 : 





int ip rcv(struct sk buff *skb, struct net device *dev, struct packet type *pt, struct net device *orig dev) 
{ 

const struct iphdr *iph; 

u32 len; 

/* 

如 果 该 数据 是 发 给 其 他 终端 的 ， 则 丢弃 这 个 数据 包 。 


这 里 的 


PKt 七 YPe 是 根据 二 层 地 址 来 判断 是 否 发 给 本 机 的 。 





*/ 
:i (skb->pkt_ type == PACKET OTHERHOST) 
goto drop; 
IP UPD PO STATS BH(dev net (dev), IPSTATS MIB IN, skb->len); 





/* 对 数据 包 进行 共享 检查 ， 保 证 


IP 协 议 处 理 的 数据 包 独 享 一 个 








skb. 
if ((skb = skb share check(skb, GFP ATOMIC)) == NULL) { 
IP INC STATS BH(dev net (dev), IPSTATS MIB INDISCARDS); 
goto out; 
} 
/* 检查 


IP 首 部 ， 如 果 数 据 包 小 于 


工 了 首部 的 大 小 ， 则 出 错 


A 
if (!pskb may pull (skb, sizeof (struct iphdr))) 


goto inhdr error; 
/* 得 到 


工 P 首 部 地 址 


A 
iph = ip hdr (skb); 
/* 根据 


REC 标 准 ， 


工 了 首部 小 于 


20 字 节 ， 或 者 版 本 号 不 是 


4 的 ， 就 报错 丢弃 
A 
if (iph->ihl < 5 || iph->version != 4) 
goto inhdr error; 
/* 根据 


工 P 首 部 指定 的 长 度 ， 再 次 检查 数据 包 的 大 小 


*] 
if (!pskb may pull (skb, iph->inl*4)) 
goto inhdr error; 
/* 重新 获取 


工 P 首 部 地 址 。 之 所 以 要 重新 获取 ， 是 因为 














Pskb may_ PuUl1 可 能 要 重新 申请 


skb */ 
iph = ip har (skb); 
/* 校 验 


工 PV4 的 校 验 和 


*/ 
if (unlikely(ip fast csum((u8 *)iph, iph->ih]l))) 
goto inhdr error; 
/* 对 数据 包 长 度 进行 检查 


*/ 
len = ntohs(iph->tot len) 
if (skb->len < len) { 
IP INC STATS BH(dev net (dev), IPSTATS MIB INTRUNCATEDPKTS); 





goto drop; 
} else if (len < (iph->ihl*4)) 
goto inhdr error; 
/* Our transport medium may have padded the buffer out. Now we know it 
* is IP we can trim to the true length of the frame. 
* Note this now means skb->len holds ntohs (iph->tot len). 
类 
/ 
/* 因为 传输 媒介 可 能 会 给 数据 包 进行 补 齐 ， 现 在 已 经 根据 





工 P 首 部 明确 了 数据 包 的 长 度 ， 因 此 需要 将 数据 


包 的 长 度 变 为 真正 的 长 度 并 改变 





if (pskb trim rcsum(skb, len)) { 
IP INC STATS BH(dev net (dev), IPSTATS MIB INDISCARDS); 
goto drop; 





/* 重 置 数 据 包 的 控制 块 信息 





Sy 
memset (IPCB (skb), 0, sizeof (struct inet skb parm)); 
/* 重 置 数据 包 的 套 接 字 信 息 





4 
skb orphan (skb); 
/* 遍历 执行 


netfilter 在 





PREROUTING 点 上 的 规则 ， 如 果 数 据 包 没有 被 丢弃 ， 则 进入 


ip rcv finish */ 
~ return NF HOOK (NFPROTO IPV4, NF INET PRE ROUTING, skb, dev, NULL, 
ip rcv finish); 加 
inhdr error: = 
IP INC STATS BH(dev net (dev), IPSTATS MIB INHDRERRORS); 
drop: 
kfree skb (skb); 
out: 
return NET RX DROP; 
} 














本 文 不 分 析 netfilter 的 相关 代码 。 数 据 包 经 过 netfilter 的 PREROUTING 处 的 规则 后 ， 进 入 了 
ip_rcv_finish， 代 码 如 下 : 





static int ip rcv finish(struct sk buff *skb) 
{ 
const struct iphdr *iph = ip hdr (skb); 
struct rtable *rt; 
/* 如 果 数 据 包 没 有 设置 路 由 信息 ， 则 进行 路 由 查询 


大 
/ 
if (skb dst(skb) == NULL) { 
int err = ip route input noref (skb, iph->daddr, iph->saddr, 
iph->tos, skb->dev); 
if (unlikely(err)) { 
/* 若 查找 路 由 失败 ， 增 加 相应 的 错误 计数 ， 并 丢弃 数据 包 





大 
/ 
if (err == -EHOSTUNREACH) 
IP INC STATS BH(dev net (skb->dev), 
IPSTATS MIB INADDRERRORS); 
else if (err == -ENETUNREACH) 
IP INC STATS BH(dev net (skb->dev), 
IPSTATS MIB INNOROUTES); 
else if (err == -EXDEV) 
NET INC STATS BH(dev net (skb->dev), 
LINUX MIB IPRPFILTER); 



































goto drop; 
} 


} 
#ifdef CONFIG IP ROUTE CLASSID 

if (unlikely(skb dst(skb)->tclassiqd)) { 
Struct ip. rt. acct. *st. = this cpu ptr(ip rt acct)y 
u32 idx = skb dst(skb)->tclassig; 
st[idx&0xFF] .0 packetst++; 
st[idx&0xFF] .0 bytes += skb->len; 
st[ (idx>>16) &OxFF] .i packetst++; 
st[ (idx>>16) &OxFF] .i bytes += skb->len; 





} 
#endif 
/* iph 大 于 


5， 即 首部 长 度 大 于 固定 首部 长 度 
2 .0 字 节 。 因 此 说 明 该 


工 P 报 文具 有 








工 了 选项 ， 于 是 调 











ip_rcv_options 处 理 
工 了 选项 


人 
if (iph->ihl > 5 && ip rcv options (Skb) ) 
goto drop; 
/* 根据 路 由 类 型 ， 增 加 相应 的 计数 


大 
/ 
rt = skb rtable (skb); 
i rt->rt type == RTN MULTICAST) { 
IP UPD PO STATS BH(dev net (rt->dst.dev), IPSTATS MIB INMCAST, 
skb->len); 0 
} else if (rt->rt type == RIN BROADCAST) 
IP UPD PO STATS BH(dev net (rt->dst.dev), IPSTATS MIB INBCAST, 
skb->len); 
/* 调用 路 由 的 输入 函数 
































类 
/ 

return dst input (skb); 
dreop: 

kfree skb (skb); 

return NET RX DROP; 





对 于 发 往 本 机 的 数据 包 来 说 ， 其 路 由 输入 函数 为 ip_local_deviver， 代 码 如 下 : 





int ip local _qeliver(Struct sk buff *skb) 
{ 
/* 该 数据 包 是 一 个 


工 P 分 片 数据 包 
*/ 
if (ip is fragment (ip hdr(skb))) { 
/* 进行 


工 了 分 片 重组 处 理 





*/ 
if (ip defrag(skb, IP DEFRAG LOCAL DELIVER)) 
return 0; 





} 
/* 遍历 执行 


netfilter 在 


LOCAL _ IN 上 的 规则 ， 如 为 丢弃 ， 则 进入 


ip local deliver finish */ 
return NEF _ HOOK (NFPROTO IPV4, NF_INET LOCAL IN, skb, skb->dev, NULL, 
ip local deliver finish); 











进入 ip local deliver finish， 代 码 如 下 : 





static int ip local deliver finishl(struct sk buff *skb) 


{ 








struct net *net = dev net (skb->dev); 
/* 拉 出 


工 了 报 文 首部 ， 因 为 马上 就 要 脱离 











IP 层 ， 进 入 传输 层 了 。 


#/ 
__Skb pull(skb, ip hdrlen (skb)); 
/* 设置 传输 层 首部 地 址 





Rp 
Skb reset transport header (skb); 
rcu read lock(); 





/* 得 到 传输 层 协议 


去/ 
int protocol = ip _hqr (skb)->protocol; 
int hash, raw; 


const struct net Protocol *ipprot; 
resubmit: 
/* 将 数据 包 传递 给 对 应 的 原始 套 接 字 




















*#/ 
raw = raw local deliver (skb, protocol); 
/* 根据 传输 协议 确定 对 应 的 
ijnet 协 议 
wy/ 
hash = protocol & (MAX INET PROTOS - 1); 
ipprot = rcu dereference(inet protos[lhash]); 
if (ipprot != NULL) { 
/* 找到 了 匹配 传输 层 的 协议 
*/ 
int ret; 
/* 检查 名 称 空间 是 否 匹配 
#/ 
if (!Inet eq(net, &init net) && !ipprot->netns ok) { 
if (net ratelimit ()) 
printk("%s: proto %d isn't netns-ready\n", 
_ func , protocol); 
kfree skb(skb); 
goto out; 
} 
/* 协议 的 安全 策略 检查 
A 
if (!ipprot->no policy) { 
if (!xfrm4 policy check (NULL, XFRM POLICY IN, skb)) { 
kfree skb (skb); 
goto out; 
} 
nf _ reset (skb); 
} 
/* 将 数据 包 传递 给 传输 层 处 理 
#/ 
ret = ipprot->handler (skb); 
if (ret < 0) { 
protocol = -ret; 
goto resubmit; 
} 
IP_INC STATS BH(net, IPSTATS MIB INDELIVERS); 
} else { 
/* 没有 对 应 的 传输 层 协议 
BA 
if (Iraw) { 
/* 车 没有 匹配 的 原始 套 接 字 ， 则 进行 安全 策略 检查 
*/ 


if (xfrm4 policy check (NULL, XFRM POLICY IN, skb)) { 
/* 若 没有 对 应 的 安全 策略 ， 则 使 

















ICMP 返 回 不 可 达 错 误 


* 
IP_INC STATS BH(net, IPSTATS MIB INUNKNOWNPROTOS); 
icmp_ send (skb, ICMP DEST UNREACH, 
ICMP PROT UNREACH, 0); 





} 
} else 

IP_INC STATS BH(net, IPSTATS MIB INDELIVERS); 
kfree skb (skb); 


} 

out: 
rcu read unlock(); 
return 0; 





14.6.5 大 师 的 错误 ? 原始 套 接 字 的 接收 





在 UNP1 的 28.4“Raw Socket Input 一 节 中 ，Stevens 大 师 是 这 样 说 的 : 


Received UDP packets and received TCP packets are never passed to a raw socket.If a process wants to 
read IP datagrams containing UDP or TCP packets, the packets must be read at the datalink layer, as described 


in Chapter 29. 
UNP1 一 书 中 文 版 的 翻译 原文 是 这 样 的 : 


接收 到 UDP 分 组 和 TCP 分 组 绝 不 传递 到 任何 原始 套 接口 。 如 果 一 个 进程 想 要 读 取 含 有 UDP 分 组 或 
TCP 分 组 的 卫 数 据 报 ， 它 就 必须 在 数据 链 路 层 读 取 这 些 分 组 。 




















对 于 中 文 版 的 翻译 ， 上 文中 的 “分 组 ”实在 是 不 专业 ， 因 为 这 不 是 一 个 准确 的 术语 。 读 者 在 看 到 这 
个 部 分 后 ， 绝 对 会 很 疑惑 。 分 组 ?何谓 分 组 ? 是 分 片 的 笔 误 还 是 组 播 ? 笔者 自己 也 是 对 照 了 英文 原版 
后 才 明白 中 文 版 的 意思 。 与 其 用 一 个 模糊 的 “分 组 ”， 还 不 如 直接 用 "“ 报 文 " 更 直截了当 。 





























回 到 正题 ， 根 据 UNP1 的 说 法 ， 普 通 的 raw socket 是 无 法 收 到 TCP 和 UDP 的 数据 包 的 ， 除 非 该 套 接 字 
是 从 数据 链 路 层 就 开始 读 取 数据 包 的 。 而 实际 上 Linux 内 核 的 实际 行为 却 不 是 这 样 的 。 下 面 让 我 们 用 代 
码 来 说 明 : 





int raw local deliver(struct sk buff *skb, int protocol) 
{ 

int hash; 

struct sock *raw sk; 

/* 根据 传输 层 协议 确定 





hash 桶 索引 


4 
hash = protocol & (RAW HTABLE SIZE - 1); 
/* 获得 该 桶 的 头 结 点 


2 
raw Sk = sk head(&raw v4 hashinfo.ht[hash]) 
/* 当头 结 点 不 为 空 时 ， 才 进入 


raw_V4 input 做 进一步 检查 


*/ 
if (raw SK && !raw v4 input (skb, ip hdr(skb), hash)) { 
/* 如 果 没 有 找到 匹配 的 原始 套 接 字 ， 则 重 置 


raw_Sk 为 


NULL. 


raw sk = NULL; 


} 


return raw sk != NULL; 





然后 进入 raw_v4_input， 代 码 如 下 : 





static int raw v4 input(struct sk buff *skb, const struct iphdr *iph, 


{ 


Stuct SOOk wok; 

struct hlist head *head; 
int delivered = 0; 
struct net *net; 

/* 与 














raw_local deliver 不 同 ， 因 为 需要 使 用 到 头 结 点 中 的 内 容 ， 所 以 需要 对 这 个 桶 上 锁 ， 才 能 保证 


w 


*7 


#/ 


4 

















在 处 理 这 个 桶 的 过 程 中 ， 所 有 节点 都 是 有 效 的 。 


read lock(g&raw v4 hashinfo.lock); 
/* 再 次 检查 头 结 点 


head = &raw v4 hashinfo.ht[hash]; 
if (hlist empty (head)) 

goto out; 
/* 获得 网 络 名 称 空间 


net = dev net (skb->dev); 
/* 查询 匹配 的 原始 套 接 字 


Sk = raw v4 lookup(net, _ sk head(head), iph->protocol, 
iph->saddr, iph->daddr, 
Skb->dev->ifindex); 

/* 若 找 到 了 匹配 的 原始 套 接 字 ， 则 继续 处 理 


while (sk) { 
delivered = 1; 
/* 如 果 数 据 包 不 是 


工 CMP 数 据 包 ， 或 者 不 是 被 指定 要 过 滤 的 


ICMP 类 型 


int hash) 


*/ 
if (iph->protocol != IPPROTO ICMP || !icmp filter(sk, skb)) { 
/* 数据 包 要 发 给 该 套 接 字 ， 需 要 


Clone 一 个 新 的 


skb */ 
struct sk buff *clone = skb clone(skb, GFP ATOMIC); 
人 六 甘 

















Clone 成 功 ， 则 调用 原始 套 接 字 的 接收 函数 





*/ 
if (clone) 
raw rcv(sk, clone); 
} 
/* 继续 查询 后 面 的 套 接 字 
uf 
Sk = raw v4 lookup(net, sk next (sk), iph->protocol, 
iph->saddr, iph->daddr, 
Skb->dev->ifindex); 
} 
out.: 


read unlock(&raw v4 hashinfo.1lock); 
return delivered; 





进入 _raw_v4 lookup， 代 码 如 下 : 





static struct sock * raw v4 lookupl(struct net *net, struct sock *sk, 
unsigned short num, be32 raddr, _be32 laddr, int dif) 
{ 


struct hlist node *node; 
/* 遍历 套 接 字 


#/ 
sk for each from(sk, node) { 
struct inet sock *inet = inet sk(sk); 
/* 
检查 如 下 几 个 条 件 : 


1) 检查 名 称 空间 。 


2) 比较 协议 号 。 


3) 如 果 套 接 字 设置 了 目的 地 址 且 地 址 相同 


4) 如 果 套 接 字 设 置 了 源 地 址 且 地 址 相同 。 


5) 如 果 套 接 字 绑 定 了 网 卡 ， 且 网 卡 相 同 。 


只 有 当 以 上 五 个 条 件 都 匹配 的 时 候 ， 该 套 接 字 才 匹 配 。 


大 
/ 
if (net eq(sock net(sk), net) && inet->inet num == num && 
! (inet->inet daddr && inet->inet daddr != raddr) && 
nee >inet rcv saddr && inet->inet rcv saddr != laddr) && 
! (sk->sk bound dev if && sk->sk bound | dev 1 =) ) 
goto found; /* gotcha */ 
} 
sk = NULL; 
found: 
return sk; 


} 





在 上 面 的 匹配 条 件 中 ， 源 地 址 、 目 的 地 址 和 绑 定 网 卡 是 原始 套 接 字 调用 connect、bind 





等 系统 调用 设 





置 的 过 滤 条 件 。 增 加 这 些 过 滤 条 件 ， 一 般 是 为 了 让 应 用 层 减 少 不 必 要 的 消耗 ， 避 免 过 滤 不 需要 过 滤 的 








数据 包 。 可 以 发 现 ， 在 原始 套 接 字 的 接收 流程 中 ， 并 没有 对 TCP 和 UDP 进行 任何 的 限制 。 








也 就 是 说 在 








Linux 环 境 下 ， 普 通 的 原始 套 接 字 完全 可 以 接受 TCP 和 UDP 的 数据 包 ， 这 与 UNP 的 描述 不 符 。 那 这 是 怎么 
回 事 呢 ? 因为 Stevens 大 师 的 UNP 针 对 的 是 Unix 环 境 的 网 络 编程 ， 而 Linux 虽 然 是 与 Unix 兼 容 的 ， 但 在 细 
节 的 实现 上 必然 与 Unix 有 所 不 同 。 需 要 注意 的 是 ，Stevens 大 师 的 另 一 本 经 典 书 籍 APUE， 也 是 针对 Unix 














环境 的 介绍 ， 在 茶 些 细节 上 肯定 会 与 Linux 环 境 有 一 定 的 出 入 。 





14.6.6 ”注册 传输 层 协议 


在 14.5.4 节 提 到 的 ip_local_deliver_finish 函 数 中 ， 内 核 通 过 调用 ipprot->handler (skb) 将 数据 包 传 递 
给 了 正确 的 传输 层 协议 。 对 于 IPv4 协 议 来 说 ， 其 传输 层 协 议 的 处 理 函 数 的 handler 是 在 inet_init 中 添加 
的 。 下 面 是 inet init 中 的 部 分 代码 : 





/* 添加 


ICMP 协 议 


4 
if (inet add _ protocol (&icmp protocol, IPPROTO ICMP) < 0) 
printk (KERN CRIT "inet init: Cannot add ICMP protocol\n"); 
/* 添加 
UDP 协议 
gh 
if (inet add protocol(&udp protocol, IPPROTO UDP) < 0) 
printk (KERN CRIT "inet init: Cannot add UDP protocol\n"); 
/* 添加 
了 TCP 协议 
4 


if (inet add protocol(&tcp protocol, IPPROTO TCP) < 0) 
printk (KERN CRIT "inet init: Cannot add TCP protocol\n"); 
#ifdef CONFIG IP MULTICAST 
/* 添加 


IGMP 协 议 


4 
if (inet add protocol(&igmp protocol, IPPROTO IGMP) < 0) 
printk (KERN CRIT "inet init: Cannot add IGMP protocol\n"); 
#endif 





通过 调用 inet_add_protocol 函 数 ， 传 输 层 将 自己 的 处 理 函 数 添加 到 了 inet protos 中 ， 这 样 就 可 以 在 
ip local deliver finish 中 调用 对 应 的 传输 层 的 处 理 函 数 了 。 


inet_init 中 的 另 一 部 分 代码 如 下 : 





for (qd = inetsw array; q < &inetsw array[INETSW ARRAY LEN]; ++q) 
inet register protosw(q); 





这 部 分 代码 用 于 注册 AF_INET 的 各 种 协议 ， 如 UDP、TCP 等 。 那 为 什么 inet 会 使 用 两 种 不 同 的 方式 


来 文 持 传 输 层 协议 的 注册 呢 ? 为 何不 合并 为 一 个 结构 呢 ? 在 笔者 看 来 ，inet_add_protocol 面 向 的 是 底层 
接口 ， 而 inet_register_protosw 面 向 的 是 上 层 应 用 ， 所 以 将 其 分 为 了 两 个 结构 。 





14.6.7 确定 UDP 套 接 字 


UDP 协 议 的 面向 底层 接口 的 处 理 结构 为 : 





static const struct net protocol udp protocol = { 
.handler = udp rcyv, 
.err handler = udp err, 
.gso_send check = udp4 ufo send check, 
.gso_segment = udp4 ufo fragment， 
.no policy = 1; 
.netns ok = 1, 





此 ， 如 果 是 UDP 数 据 包 ， 会 依次 进入 udp_ rcv 一 ”udp4 lib rcev， 下 面 来 看 看 _udp4 lib rcv 的 相 
关 代 码 : 





int _ udp4 lib rcv(struct sk buff *skb, struct udp table *udptable, 
int proto) 
{ 


struct Sook *Sk; 

Strict Uhdre wuh; 

unsigned short ulen; 

struct rtable *rt = skb rtable (skb); 
_ be32 saddr, daddr; 

struct net *net = dev net (skb->dev); 
/* 校 验 数据 包 至 少 要 有 





UDP 首 部 大 小 
“7 
if (lpskb may pull(skb, sizeof(struct udphdr))) 
goto drop; /* No space for header. */ 
/* 得 到 
UDP 首 部 指针 
*/ 
uh = udp hdr (skb); 
/* 得 到 


UDP 数据 包 长 度 、 源 地 址 、 目 的 地 址 


*/ 
ulen = ntohs (uh->len); 


saddr = ip hdr (skb)->sadgddr; 
daddr = ip hdr (skb)->daddr; 
/* 如 果 


UDP 数 据 包 长 度 超过 数据 包 的 实际 长 度 ， 则 出 错 


二 
if (ulen > skb->len) 
goto short packet; 
7 
判断 协议 是 否 为 


UDP 协议 。 


也 许 有 的 读者 会 觉得 很 奇怪 ， 为 什么 在 


UDP 的 接收 函数 中 还 要 判断 协议 是 否 为 



































UDP? 
因为 这 个 函数 还 用 于 处 理 
UDPLITE 协 议 。 
*/ 
if (proto == IPPROTO UDP) { 
/* 如 果 是 


UDP 协议 ， 则 将 数据 包 的 长 度 更 新 为 


UDP 指定 的 长 度 ， 并 更 新 校 验 和 





4 
if (ulen < sizeof(*uh) || pskb trim rcsum(skb, ulen)) 
goto short packet; 
/* 因为 前 面 的 操作 可 能 会 导致 





Skb 内 存 变 化 ， 所 以 需要 重新 获得 





UDP 首 部 指针 


* 


. 
/* 初始 化 


uh = udp hdr (skb); 


UDP 校 验 和 


*/ 
if (udp4 csum init(skb, uh, proto)) 
goto csum error; 
/* 如 果 路 由 标志 位 广播 或 多 播 ， 则 表明 该 


UDP 数据 包 为 广播 或 多 播 


*/ 
下 (rt~>rt, flags & (RTCF_ BROADCAST | RTCF MULTICAST)) 
return udp4 lib mcast deliver (net, skb, uh, 
saddr, daddr, udptable); 





/* 确定 匹配 的 


UDP 套 接 字 


sk = udp4 lib lookup skb(skb, uh->source, uh->dest, udptable); 
if (sk != NULL) { 
/* 找到 了 匹配 的 套 接 字 





*/ 
/* 将 数据 包 加 入 到 
UDP 的 接收 队列 
int ret = udp queue rcv skb(sk, skb); 
sock put (sk); 
/* a return value > 0 means to resubmit the input, but 
* it wants the return to be -protocol, or 0 
*/ 
if (ret > 0) 
return. Eety 
return 0; 
} 
/* 进行 
又 frm 策 略 检 查 
0 
if (!xfrm4 policy check (NULL, XFRM POLICY IN, skb)) 
goto drop; 
/* 重 置 





netfilter 信 息 


*/ 
nf_ reset (skb); 
/* 检查 


UDP 检验 和 


4 
if (udp lib checksum complete (skb)) 
goto csum error; 
/* 车 不 知道 匹配 的 


UDP 套 接 字 ， 则 发 送 


ICMP 错 误 消 息 


本 
UDP_INC STATS BH(net, UDP MIB NOPORTS, proto == IPPROTO UDPLITE); 
icmp send (skb, ICMP DEST UNREACH, ICMP PORT UNREACH, 0); 
人 


* Hmm. We got an UDP packet to a port to which we 
* don't wanna listen. Ignore it. 
兴 / 

kfree skb (skb); 

return 0; 

/* 错误 处 理 








下 面 来 看 一 下 如 何 匹 配 UDP 套 接 字 ， 请 看 _udp4 lib lookup skb 一 ”udp4 lib lookup 函 数 ， 代 码 如 
下 : 





static struct sock * udp4 lib lookup(struct net *net, _ be32 sadgr, 
_ bel6 sport, _be32 daddr, bel6 dport, 
int dif, struct udp table *udptable) 


struct sock *sk, *result; 

struct hlist nulls node *node; 
unsigned short hnum = ntohs (dport); 
/* 使 用 目的 端口 确定 

















hash 桶 索引 


大 
/ 
unsigned int hash2, slot2, slot = udp hashfn(net, hnum, udptable->mask); 
struct udp hslot *hsilot2, *hsilot = &udptable->hash[lslot]; 
int score, badness; 
rcu read lock(); 
/* 若 该 桶 的 套 接 字 个 数 多 于 


1 0 个 ， 则 需要 再 次 定位 


#/ 
if (hslot->count > 10) { 
/* 使 用 目的 地 址 和 目的 端口 确定 

















hash 桶 索引 


要/ 
hash2 = udp4 portaddr hash (net, daddr, hnum); 
Slot2 = hash2 & udptable->mask; 
/* 
UDP 套 接 字 表 维护 了 两 个 


Phash 表 : 


第 一 个 

















hash 表 ， 使 用 端口 来 索引 。 














hash 表 ， 使 用 地 址 











十 端口 来 索引 。 


在 进行 











UDP 套 接 字 匹配 的 时 候 ， 优 先 使 用 第 一 个 














hash 表 ， 因 为 第 一 个 























hash 表 使 用 的 是 端口 进行 散 





列 索引 ， 那 么 只 要 端口 相同 ， 无 论 是 监听 的 指定 





工 了 还 是 任意 


IP， 都 可 以 在 一 个 桶 中 进行 匹配 。 但 





65535 种 可 能 ， 所 以 可 能 导致 不 够 分 散 ， 一 个 桶 的 套 接 字 个 数 会 比较 多 。 而 第 二 个 











hash 表 是 使 用 地 址 











十 端口 来 索引 的 ， 因 此 理论 上 套 接 字 的 分 布 会 比 第 一 个 


hash 表 更 加 分 散 。 


因此 当 第 一 个 


hash 表 对 应 桶 的 套 接 字 多 于 


1 0 个 时 ， 内 核 会 尝试 去 第 二 个 





hash 表 中 进行 匹配 查找 。 


Ry 
hslot2 = &udptable->hash2[slot2]; 
/是 管 第 三 站 


hash 表 理论 上 会 比 第 一 个 


























hash 表 分 散 ， 但 是 如 果实 际 上 第 二 个 表 的 桶 中 套 接 字 个 数 大 于 第 一 个 表 的 桶 中 套 接 字 个 数 ， 那 么 这 时 还 是 利用 第 一 个 


hash 表 进行 匹配 


4 
if (hslot->count < hslot2->count) 
goto begin; 
/* 在 第 三 个 


hash 表 的 桶 中 匹配 查找 套 接 字 


大 
/ 
result = udp4 lib lookup2 (net, saddr, sport, 
“daddr, hnum, dif, 
nslGt2.. S16t2)3 
if (!result) { 
/* 车 利用 指定 的 























IP 和 端口 在 该 桶 中 没 能 找到 匹配 的 套 接 字 ， 则 通常 使 用 任意 

















工 P+ 端 口 来 进行 


散 列 索引 


大 
/ 
hash2 udp4 portaddr hash (net, htonl (INADDR ANY), hnum); 
slot2 hash2 & udptable->mask; 
hslot2 = &udptable->hash2[slot2]; 
/* 还 是 要 与 第 一 个 


hash 桶 中 的 个 数 进行 比较 





汪 冰 
if (hslot->count < hslot2->count) 
goto begin; 
/* 在 第 二 个 











hash 表 中 使 用 任意 








IP+ 端 口 进行 匹配 查找 





6 
result = udp4 lib lookup2 (net, saddr, sport, 
htonl (INADDR ANY), hnum, dif, 
hslot2; ‘Slot2); 
} 
rcu read unlock(); 
return result; 
} 
begin: 
result = NULL; 
badness = -1; 
7* 省 第 一 省 
hash 表 的 桶 中 进行 查找 
要/ 


sk nulls for each rcul(sk, node, &hslot->head) { 
/* 计算 该 套 接 字 的 匹配 得 分 





大 
/ 
score = compute score(sk, net, saddr, hnum, sport, 
daddr, dport, dif); 
/* 保证 匹配 得 分 最 高 的 套 接 字 为 最 终结 
Rp 
if (score > badness) { 
result = sk; 
badness = score; 
} 
} 
/* 


检查 在 查找 的 过 程 中 ， 是 否 遇 到 了 某 个 套 接 字 被 移 到 另外 一 个 桶 内 的 情况 。 





这 时 ， 需 要 重新 进行 匹配 。 





赤 / 
if (get nulls _ value (node) != slot) 
goto begin; 
/* 找到 了 匹配 的 套 接 字 


*/ 
if (result) { 
/* 增加 套 接 字 引用 计数 




















4 
if (unlikely(!atomic inc not zero hint (gresult->sk refcnt, 2))) 
result = NULL; 
/* 再 次 计算 套 接 字 得 分 ， 如 小 于 最 大 分 数 ， 则 重新 匹配 查找 。 之 所 以 做 二 次 检查 ， 也 是 为 了 防止 在 




















匹配 与 增加 引用 的 过 程 中 ， 套 接 字 发 生变 化 。 





大 
/ 
else if (unlikely (compute scorel(result, net, saddr, hnum, sport, 
daddr, dport, dif) < badness)) { 
sock put (result); 
goto begin; 
} 
} 
rcu read unlock(); 
return result; 








从 上 面 的 代码 中 可 以 看 到 ，[ 匹 配 UDP 套 接 字 的 关键 在 于 对 应 套 接 字 的 匹配 得 分 。 第 一 个 hash 表 的 得 
分 计算 函数 为 compute_score。 





static inline int compute score(struct sock *sk, struct net *net, _ be32 sadgdr, 
unsigned Short hnum, 
_ bel16 sport, be32 daddr, _be16 dport, int dif) 


int Score = -1;} 
/* 比较 名 称 空间 ， 端 口 等 


大 
/ 
if (net eq(sock net(sk), net) && udp sk(sk)->udp Port hash == hnum && 
!ipv6é only sock(sk)) { 
struct inet sock *inet = inet sk(sk); 
/* 若 套 接 字 指明 为 


PF_INET， 则 加 





1 闪 

*/ 
score = (sk->sk family == PF INET ? 1 :; 0); 
/* 套 接 字 绑 定 了 接收 地 址 

4 


if (inet->inet rcv saddr) { 
/* 如 果 数 据 包 的 目的 地 址 与 绑 定 接收 地 址 不 符 ， 则 分 数 为 


一 ] ， 相 同 则 增加 


机 
if (inet->inet rcv saddr != daddr) 


return -1; 
score += 2; 


} 
/* 套 接 字 设置 了 对 端 目的 地 址 


办 
if (inet->inet daddr) { 
/* 如 果 数 据 包 的 源 地 址 与 设置 的 目的 地 址 不 同 ， 则 分 数 为 


一 ] ， 相 同 则 增加 


2 务 
*/ 
if (inet->inet daddr != sagddr) 
return -1; 
Score += 2; 
} 
/* 套 接 字 设 置 了 对 端 目 的 端口 
*] 


if (inet->inet dport) { 
/* 如 果 数 据 包 的 源 端 口 与 设置 的 目的 端口 不 同 ， 则 分 数 为 


一 ] ， 相 同 则 增加 


2 分 
*/ 
if (inet->inet dport != sport) 
return -1; 
score += 2; 
} 
/* 套 接 字 绑 定 了 网 卡 
Rp 


if (sk->sk bound dev if) { 
/* 如 果 接 受 数据 包 的 网 卡 与 绑 定 网 卡 不 同 ， 则 分 数 为 


一 ] ， 相 同 则 增加 


大 
/ 
if (sk->sk bound dev if != dif) 
return -1; 
score += 2; 
} 
} 


return SCCFEe 





对 于 第 二 个 hash， 其 匹配 分 数 计算 函数 为 compute_score2， 算 法 与 compute_score 基 本 相同 。 总 的 来 


说 UDP 的 套 接 字 匹配 有 以 下 几 个 条 件 : 





接收 端口 : 必须 匹配 。 





.接收 地 址 : 如 绑 定 了 则 必须 匹配 ， 分 值 为 2 分 。 





.对 端 目的 地 址 : 如 设置 了 则 必须 匹配 ， 分 值 为 2 分 。 





.对 端 目的 端口 ， 如 设置 了 则 必须 匹配 ， 分 值 为 2 分 。 
网卡， 如 绑 定 了 则 必须 匹配 ， 分 值 为 2 分 。 


. 套 接 字 设置 了 PF JINET 协 议 族 ， 分 值 为 1 分 。 





根据 上 面 的 规则 ， 匹 配 分 值 最 高 的 套 接 字 就 为 选中 的 UDP 套 接 字 ， 然 后 内 核 会 将 这 个 数据 包 加 入 
到 该 UDP 套 接 字 的 接收 队列 中 。 也 就 是 说 ， 即 使 数据 包 可 以 匹配 多 个 UDP 套 接 字 《〈 这 是 很 有 可 能 的 ) ， 
但 是 最 终 也 只 有 一 个 最 匹配 的 套 接 字 会 被 选中 ， 并 且 只 有 这 个 套 接 字 可 以 收 到 数据 包 。 























有 一 些 开 发 人 员 想 使 用 套 接 字 的 SO_REUSEADDR 选 项 ， 让 多 个 套 接 字 绑 定 同一 个 地 址 或 端口 ， 然 
后 让 独立 的 线程 或 进程 负责 一 个 套 接 字 的 处 理 ， 希 望 利用 这 样 的 设计 来 提高 服务 的 响应 速度 。 这 里 面 
有 个 想当然 的 认为 ， 当 多 个 套 接 字 负责 同一 个 地 址 和 端口 的 数据 包 接 收 时 ， 它 们 可 以 分 担负 载 。 然 而 
从 上 面 的 源码 分 析 中 ， 我 们 可 以 发 现 这 样 的 设计 方案 是 达 不 到 预期 效果 的 。 因 为 内 核 在 进行 套 接 字 的 
匹配 时 ， 对 于 绑 定 相同 地 址 和 端口 的 多 个 套 接 字 ， 每 次 只 会 命中 同一 个 套 接 字 。 结 果 在 上 面 的 设计 
中 ， 只 有 一 个 套 接 字 会 收 到 数据 包 ， 也 就 说 最 后 只 有 一 个 线程 或 进程 在 处 理 数据 包 。 







































































不 过 Linux 内 核 在 3.9 版 本 中 引入 了 一 个 新 的 套 接 字 选项 SO_REUSEPORT 用 于 解决 上 面 的 问题 。 当 多 
个 套 接 字 绑 定 于 同一 个 地 址 和 端口 时 ， 并 启用 了 SO_REUSEPORT 时 ， 内 核 会 自动 在 这 几 个 套 接 字 之 间 
做 负载 均衡 ， 保 证 对 应 的 数据 包 能 尽量 平均 地 分 配 到 不 同 的 套 接 字 上 。 

















14.6.8 ”确定 TCP 套 接 字 


TCP 面 向 底层 接口 的 处 理 结构 为 : 





static const struct net protocol tcp _ Protocol = { 


.handler = tcp v4 rcv, 

.err handler = tcp v4 err, 

.gso_ send check = tcp v4 gso send check, 
.gso_ segment = tcp tso segment, 
.gro_receive = tcp4 gro receive, 
.gro_ complete = tcp4 gro complete, 
.no policy = Ls 

.netns ok = DD; 





那么 ， 如 果 是 TCP 数 据 包 ， 则 会 进入 tcp_v4 rcv， 


代码 如 下 : 





int tcp v4 rcv(struct sk puff *skb) 
{ 
const ‘struct iphadr *iph; 
const struct tcphdr *th; 
struct sock *sk; 
int ret; 
struct net *net = dev net (skb->dev); 
/* 丢弃 不 是 发 给 自己 的 数据 包 





守 
/ 
if (skb->pkt type != PACKET HOST) 
goto discard it; 
/* Count it even if it's bad */ 
TCP_INC STATS BH(net, TCP MIB INSEGS); 
/* 检查 数据 包 至 少 要 有 








TCP 固定 首部 的 大 小 


4 
if (!Ipskb may pull(skb, sizeof(struct tcphdr))) 
goto discard it; 
/* 获得 


了 TCP 首部 地 址 


#/ 
th = tcp hdr (skb); 
/* 检查 


了 CP 的 数据 偏 移 量 是 否 合法 


， 不 能 小 于 


TCP 固定 首部 的 大 小 


*/ 
if (th->doff < sizeof(struct tcphdr) / 4) 


goto bad packet; 


/* 检查 数据 包 的 大 小 是 否 满足 


了 CP 指定 的 数据 偏 移 位 置 


a 
if (!pskb may pull (skb, th->doff * 4)) 
goto discard it; 
/* 如 果 需 要 检查 校 验 和 ， 则 进行 校 验 和 初始 化 


| 
if (!skb csum unnecessary (skb) && tcp v4 checksum init (skb)) 
goto bad packet; 
/* 因为 


Skb 可 


侠 
阔 


重新 申请 ， 所 以 需要 重新 得 到 














了 TCP 首部 


了 CP 报 文 信息 ， 设 置 


日 








Skb 的 
TCP 控制 块 
证 
TCP_SKB_ CB (skb)->seq = ntoh] (th->seq); 
TCP SKB CB (skb)->end seq = (TCP SKB CB(skb)->seq + th->syn + th->fin + Skb-> len ~ th->doff * 4)7 
TCP_SKB CB (skb)->ack seq = ntohl (th->ack seq); 
TCP_SKB_ CB (skb) ->when = 0; 
TCP_ SKB CB (skb)->ip dsfield = ipv4 get dsfield(iph); 
TCP_SKB CB (skb)->sacked = 0; 
/* 查找 匹配 的 
TCP 套 接 字 
*/ 
sk = _ inet lookup skb(&tcp hashinfo, skb, th->source, th->dest); 
if (lsk) 


goto no tcp socket; 
/* 找到 匹配 的 套 接 字 并 开始 处 理 ， 因 为 不 是 本 文 重点 ， 因 此 省 略 后 面 的 分 析 








4 
process: 





进入 _inet lookup skb-> inet lookup。 





static inline struct sock * inet lookupl(struct net *net, 
struct inet hashinfo *hashinfo, 
const be32 saddr, const _ bel16 sport, 


const be32 daddr, const be16 dport, 
const int dif) 


ul6 hnum = ntohs (dport); 
/* 先 在 已 连接 的 套 接 字 中 进行 查找 





过 
struct sock *sk = inet lookup_established(net，hashinfoyv 
saddr, sport, daddr, hnum, dif); 
/* 优先 使 用 已 连接 的 套 接 字 ， 若 没有 找到 ， 则 在 监听 的 套 接 字 中 进行 查找 




















六 
return sk ? : _ inet lookup 1istener (net，hashinfo，qaddqr，hnum，dqif) 





对 于 TCP 来 说 ， 套 接 字 的 匹配 分 为 两 部 分 : 一 个 是 匹配 已 经 建立 连接 的 ， 另 外 一 个 是 匹配 监听 状 
的 套 接 字 。 我 们 先 来 看 看 前 者 ， 即 已 经 建立 连接 的 ， 进 入 _ inet lookup_established， 代 码 如 下 : 








太 


yu 





struct sock * _ inet lookup established(struct net *net, 
struct inet hashinfo *hashinfo, 


const be32 saddr, const bel16 sport, 
const _ be32 daddr, const ul6 hnum, 
const int dif) 





INET ADDR COOKIE (acookie, saddr, daddr) 
const _portpair ports = INET COMBINED PORTS (sport, hnum); 
struct sock *sk; 
const struct hlist nulls node *node; 
/* Optimize here for direct hit, only listening connections can 
* have wildcards anyways. 
大 
/ 
/* 根据 目的 地 址 、 目 的 端口 、 源 地 址 、 源 端口 计算 得 到 已 经 连接 了 





hasSh 表 的 桶 索引 


大 
unsigned int hash = inet ehashfn(net, daddr, hnum, saddr, sport); 
unsigned int slot = hash & hashinfo->ehash mask; 
struct inet ehash bucket *head = &hashinfo->ehash[slot]; 
rcu read lock(); 
begin: 
/* 遍历 该 桶 节点 


*/ 
sk nulls for each rcul(sk, node, &head->chain) { 
/ 大 
比较 源 地 址 、 目 的 地 址 、 源 端口 、 目 的 端口 及 接收 网 卡 。 





细心 的 读者 会 发 现 这 里 有 两 个 参数 


acookie 和 














Ports， 这 两 个 参数 用 于 加 速 匹 配 。 在 





64 位 机 器 上 ， 


acCOoOK1ie 为 源 地 址 和 目的 地 址 合成 的 


64 位 整数 ， 在 


32 位 机 器 上 


aCOOKkie 并 无 意义 。 


Ports 为 源 端 


口 和 目的 端口 合成 的 


32 位 整数 。 通 过 直接 比较 组 合 的 整数 ， 可 以 加 速 匹配 。 


发炎 
if (INET MATCH(sk, net, hash, acookie, 
saddr, daddr, ports, dif)) { 
/* 增加 套 接 字 引用 计数 




















水 人 
if (unlikely(!atomic inc not zero(&sk->sk refcnt) ) ) 
goto begintw; 
/* 
再 次 检测 ， 防 止 套 接 字 在 


INET_ MATCH 和 增加 计数 之 间 被 改变 


大 

/ 

if (unlikely(!INET MATCH(sk, net, hash, acookie, 
saddr, daddr, ports, dif))) 1 
sock put (sk); 
goto begin; 





} 
EGG OU 


} 
/* 
* if the nulls value we got at the end of this lookup is 
* not th xpected one, we must restart lookup. 
* We probably met an item that was moved to another chain. 





SY 
if (get nulls value (node) != slot) 
goto begin; 
begintw: 


/* 如 果 在 已 经 连接 的 


hasSh 表 中 找 不 到 对 应 的 套 接 字 ， 则 需要 到 连接 为 





TIME WAIT 状态 的 





hash 表 中 查找 








套 接 字 ， 原 理 与 上 面相 同 。 这 说 明 


TIME WAIT 状 态 的 连接 如 果 依然 存在 ， 则 会 优先 于 监听 套 接 字 。 





大 
/ 
sk nulls for each rcul(sk, node, &head->twchain) { 
if (INET TW MATCH(sk, net, hash, acookie, 
Saddry daddr, ports; dif)) 1 
if (unlikely(!atomic inc not zero(&sk->sk refcnt))) { 
sk = NULL; 站 加 
goto out; 








} 
/* 与 上 面 一 样 ， 需 要 再 次 进行 匹配 检查 





*/ 
if (unlikely(!INET TW MATCH (sk, net, hash, acookie, 
saddr, daddr, ports, dif))) 1 
sock put (sk); 
goto begintw; 
} 
ESG OU 
} 
} 
/* 省 略 
*/ 





如 果 在 已 经 连接 和 TIME_WAIT 状 态 的 hash 表 中 ， 都 没有 找到 匹配 的 套 接 字 。 这 时 就 需要 到 监听 
hash 表 中 查找 匹配 的 套 接 字 ， 代 码 如 下 : 





struct sock * inet lookup listener(struct net *net, 
struct inet hashinfo *hashinfo, 
const _be32 daddr, const unsigned short hnumv 
const int dif) 


struct sock *sk, *result; 
struct hlist nulls node *node; 
/* 根据 源 端 口 计算 监听 





hash 表 对 应 的 桶 索引 


大 
/ 
unsigned int hash = inet lhashfn (net, hnum); 
struct inet listen hashbucket *ilb = &hashinfo->listening hashlhash]; 
int score, hiscore; 己 
rcu read lock(); 


begin: 
result = NULL; 
hiscore = -1; 


/* 遍历 该 桶 中 的 套 接 字 ， 与 





UDP 相 似 ， 得 分 最 高 的 套 接 字 为 匹配 套 接 字 


Ry 
sk nulls for each rcul(sk, node, &ilb->head) { 
/* 计算 套 接 字 的 得 分 








大 
/ 
Score = compute score(sk, net, hnum, dagddr, dif); 
if (score > hiscore) { 
result = sk; 
hiscore = score; 
} 
} 
7 
* if the nulls value we got at the end of this lookup is 
太 not. th xpected one, we must restart lookup. 
* We probably met an item that was moved to another chain. 
大 
/ 
if (get nulls value (node) != hash + LISTENING NULLS BASE) 


goto begin; 
/* 找到 了 匹配 的 套 接 字 

















4 
if (result) { 

/* 增加 套 接 字 引用 计数 

*/ 
if (unlikely(!atomic inc not zero(&result->sk refcnt) ) ) 

result = NULL; 

/* 需要 再 次 检查 该 套 接 字 的 得 分 

A 


else if (unlikely (compute scorel(result, net, hnum, daddr, 
dif) < hiscore)) { 
sock put (result); 
goto begin; 
} 
} 


rcu read unlock () ; 
return result; 








匹配 TCP 监 听 套 接 字 的 流程 与 UDP 基本 相同 ， 都 是 在 计算 套 接 字 的 得 分 。 下 面 我 们 来 看 一 下 TCP 监 


上 听 套 接 字 的 得 分 计算 函数 compute_score。 





static inline int compute score(struct sock *sk, struct met *net, 
const unsigned short hnum const _be32 daddr, 
const int dif) 


int Score = -1; 
struct inet sock *inet = inet sk(sk); 


/* 必须 匹配 名 称 空间 和 目的 端口 


*/ 
if (net eql(sock net(sk), net) && inet->inet num == hnum && 


!ipv6é only sock(sk)) { 
__be32 rcv_ saddr = inet->inet rcv_ saddr; 
/* 若 协 议 族 为 


PF_INET， 则 得 分 加 


1 */ 
score = sk->sk family == PF INET ? 1 : 0; 
/* 一 一 
若 套 接 字 指 定 了 接收 地 址 ， 则 接收 地 址 必须 与 目的 地 址 相同 。 





不 同 则 不 匹配 ， 相 同 则 得 分 加 


if (rcv saddr) { 
if (rcv saddr != daddr) 
return -1; 
score += 2; 
} 
/* 
如 果 套 接 字 绑 定 了 网 卡 ， 则 接收 网 卡 必须 相同 。 


不 同 则 不 匹配 ， 相 同 则 得 分 加 


大 
/ 
if (sk->sk bound dev if) { 
if (sk->sk bound dev if != dif) 
return -1l; 
Score += 2; 
} 
} 


return SOorey 








这 个 函数 的 名 字 和 功能 均 与 UDP 的 相同 ， 但 是 其 实现 代码 却 略 有 不 同 。 大 家 可 以 发 现 ，TCP 的 
compute_ score 不 会 对 源 端 信息 进行 任何 检查 ， 如 源 地 址 、 源 端口 等 。 为 什么 会 这 样 呢 ? 原因 在 于 ，TCP 
的 compute_score 是 用 于 监听 套 接 字 的 匹配 的 。 这 就 意味 着 这 是 TCP 连 接 的 第 一 个 数据 包 即 SYN 包 ， 属 于 
连接 初始 化 阶段 ， 这 时 自然 无 须 对 源 端 信息 进行 任何 的 检查 和 匹配 。 在 本 机 回复 了 SYN+ACK 后 ， 本 机 
会 创建 已 连接 套 接 字 并 插入 到 已 连接 hash 表 中 。 这 样 在 此 连接 后 面 的 数据 包 ， 就 会 在 已 连接 的 hash 表 中 
找到 匹配 的 套 接 字 ， 而 不 会 再 进入 监听 套 接 字 的 匹配 。 














中 























第 15 章 ”编写 安全 无 错 代 码 





通过 前 面 的 章节 ， 主 要 是 学 习 和 分 析 在 Linux 环 境 下 不 同方 面 的 系统 调用 及 内 核实 现 。 本 章 则 将 分 
享 笔 者 多 年 编程 的 一 些 经 验 ， 主 要 是 从 基础 概念 出 发 ， 介 绍 一 些 编码 细节 ， 这 些 细节 看 上 去 有 些 分 
散 ， 有 点 奇 技 淫 巧 的 味道 ， 但 笔者 的 主要 目的 是 为 了 让 大 家 从 心里 明白 编写 安全 无 错 代码 的 不 易 。 要 
对 代码 有 敬 娠 之 心 ， 才 能 真正 驾驭 代码 ， 写 出 健壮 的 程序 。 
































15.1 不 要 用 memcmp 比 较 结构 体 





























比较 两 个 结构 体 时 ， 若 结构 体 中 含有 大 量 的 成 员 变 量 ， 为 了 方便 ， 程 序 员 往 往 会 直接 使 用 memcmp 
对 这 两 个 结构 体 进 行 比较 ， 以 避免 对 每 个 成 员 进 行 分 别 比较 。 这 样 的 代码 写 起 来 比较 简单 ， 然 而 却 很 
可 能 深 藏 隐患 。 请 看 下 面 的 示例 代码 : 











#include <stdio.h> 

#include <stdlib.h> 

#include <string.h> 

typedef struct padding type { 
Short ml; 加 
jnt 和 27 

} padding type t; 

int main() 


padding type t a= { 
.ml = 0, 
.m2 = 0， 

}; 

padding type t b; 

memset (&b, 0, sizeof (pb)); 


if (0 == memcmp(&a, &b, sizeof(a))) { 
printf ("Equal!\n"); 





else 1{ 
printf ("No equal!\n"); 


return 0; 





大 家 先 想 一 下 ， 结 果 会 是 什么 ? 一 起 来 看 看 最 终 的 结 





[fgao@ubuntu chapter15]#gcc -Wall 15 1 cmp struct.c 
[fgao@ubuntu chapter15]#./a.out 
No equal! 











为 什么 会 是 这 样 的 结果 呢 ? 有 经 验 的 读者 立刻 就 会 反应 过 来 : 这 是 由 于 对 齐 造 成 的 。 


没 错 ! 就 是 因为 struct padding type->ml 的 类 型 是 short 类 型 ， 而 m2 的 类 型 是 int 类 型 。 根 据 自然 对 齐 
规则 ，struct padding type 需 要 进行 4 字 节 对 齐 。 因 此 编译 器 会 在 ml 后 面 插入 两 个 padding 字 节 ， 而 这 两 个 
字 节 的 内 容 却 是 “随机 ”的 。 结 构 体 b 由 于 调用 了 memset 对 整个 结构 体 占用 的 内 存 进行 了 清 零 ， 其 padding 
的 值 自然 就 为 0。 这 样 ， 当 使 用 memcmp 对 两 个 结构 体 进行 比较 时 ， 结 论 就 是 不 相同 了 ， 即 返回 值 不 为 
0。 














所 以 ， 除 非 在 项 目 中 可 以 保证 所 有 的 结构 体 都 会 使 用 memset 来 进行 初始 化 (这 个 是 很 难保 证 
的 ) ， 人 否则 就 不 要 直接 使 用 memcmp 来 比较 结构 体 。 











15.2 ”有 符号 数 和 无 符号 数 的 移 位 区 别 














在 代码 规范 中 一 般 都 会 要 求 ， 如 果 没 有 符号 要 求 ， 则 尽量 使 用 无 符号 整数 ， 避 免 使 用 有 符号 整 














数 。 因 为 有 符号 整数 在 一 些 常 见 的 操作 中 ， 将 表现 出 与 无 符号 整数 大 相 径 庭 的 行为 。 本 闻 将 展示 有 符 
号 整数 与 无 符号 整数 在 移 位 操作 上 的 区 别 。 来 看 一 个 示例 : 





#include <stdio.h> 
#include <stdlib.h> 
int main () 
{ 

int a = 0x80000000; 


unsigned int b = 0x80000000; 
printf("a right shift Value is Ox%X\n", a >> 1); 
printf("b right shift value is Ox%X\n", b >> 1); 





return 0; 
} 
其 输出 结果 为 : 





[fgao@ubuntu chapter15]#gcc -Wall 15 2 sign shift.c 


[fgao@ubuntu chapter15]#./a.out 


a right shift value is 0xC0000000 
b right shift value is 0x40000000 





为 了 了 解 为 什么 会 产生 这 样 的 结 





请 看 其 汇编 代码 : 





Dump of assembler code for function main: 


0x0804841d <+0>: 
0x0804841le <+1>: 
0x08048420 <+3>: 
0x08048423 <+6>: 
0x08048426 <+9>: 
Ox0804842e <+17>: 
0x08048436 <+25>: 
0x0804843a <+29>: 
0x0804843c <+31>: 
0x08048440 <+35>: 
Ox08048447 <+42>: 
0x0804844c <+47>: 
0x08048450 <+51>: 
0x08048452 <+53>: 
0x08048456 <+57>: 
0x0804845d <+64>: 
0x08048462 <+69>: 
Ox08048467 <+74>: 
0x08048468 <+75>: 
End of assembler dump. 











push 


Sebp 

Sesp, Sebp 
$0Oxfffffff0,%esp 
$0x20, Sesp 
$0x80000000, 0x18 (Sesp) 
$0x80000000, 0xlc (Sesp) 
0X18 (Sesp), Seax 

Seax 

Seax, Ox4 (Sesp) 
$0x8048500, (Sesp) 
0x80482f0 <printf@plt> 
Oxlc (Sesp) ,Seax 

Seax 

Seax, Ox4 (Sesp) 
$0x804851d, (Sesp) 
0x80482f0 <printf@plt> 
$0x0, Seax 





0x80000000 在 内 存 或 寄存 器 中 的 布局 如 图 15-1 所 示 。 


[Else || 


0x80000000 在 内 存 或 寄存 器 中 的 布局 


图 15-1 


其 中 第 一 位 “1” 即 符号 位 。 


0x0804843a 地 址 对 应 的 是 a>>1 的 汇编 代码 ，sar 为 算术 右 移 ， 其 使 月 
补 位 。0x08048450 地 址 对 应 的 是 b>>1 的 汇编 代码 ，shr 为 逻辑 右 移 ， 其 使 用 0 补 位 。 这 就 造成 了 最 终结 





符号 位 补 位 。 对 于 此 例 ， 即 用 1 


果 


的 不 同 。 


1$.3 ”数组 和 指针 


对 于 这 个 标题 ， 可 能 很 多 读者 都 会 认为 数组 和 指针 ， 几 乎 没有 什么 区 别 。 确 实 ， 在 大 多 数 的 情况 
下 ， 数 组 和 指针 的 区 别 并 不 大 ， 甚 至 可 以 互 换 。 然 而 ， 这 两 者 实际 上 是 有 本 质 区 别 的 。 而 这 个 区 别 也 
会 导致 并 不 是 所 有 的 情况 下 ， 两 者 都 可 以 互 换 。 同 样 来 看 一 个 示例 : 














#include <stdlib.h> 
#include <stdio.h> 
int main() 

{ 


int array[4] = {0}; 


int *pointer = NULL; 
int value = 0; 

value = array; 

value = &array; 
Value = array[0]; 
Value = &array[0]; 
value = point; 
value = &point; 
return 0; 








对 其 反 汇编 ， 来 分 析 数 组 和 指针 的 本 质 。 分 析 的 过 程 将 直接 写 在 反 汇编 的 代码 中 : 








Dump of assembler code for function main: 





0x080483ed <+0>: push Sebp 
0x080483ee <+1>: mov Sesp, Sebp 
0x080483f0 <+3>: sub $0x20, Sesp 
pg 大 
下 面 

4 行 对 应 

C 代 码 


int array[4] = {0}; 
这 里 说 明 数 组 只 是 一 个 同类 型 变量 的 内 存 空间 的 集 


高 
中 








这 个 例 


| 


中， 





array 是 在 栈 上 申请 了 


4 个 整 型 变量 的 空间 。 
*/ 
Ox080483f£3 <+6>: movl $0x0, -0x10 (Sebp) 
0x080483fa <+13>: movil $0x0,—-0xc (sebp) 
Ox08048401 <+20>: movil $0x0, -0x8 ($ebp) 
Ox08048408 <+27>: movl $0x0, -0x4 (Sebp) 


/* 
这 行 对 应 的 


C 代 码 为 


int *pointer = NULL. 
这 说 明 指针 本 身 也 是 一 个 变量 ， 同 样 占用 了 栈 空间 。 
































32 位 机 器 上 ， 其 占 





4 字 节 。 





























数组 和 指针 对 比 ， 其 占用 的 空间 实际 上 是 数组 中 元 素 占 用 的 空间 之 和 。 

















本 例 中 ， 即 





array[l0],array[l1],array[l2],array[3], 而 


array 本 身 实 际 上 更 像 是 一 个 


label. 
*/ 
0x0804840f <+34>: movil $0x0, -0x18 (Sebp) 
/* 这 行 对 应 的 
C 代 码 为 


int value = 0; */ 
0x08048416 <+41>: movil $0x0, -0x14 (Sebp) 
/* 
下 面 两 行 对 应 的 





C 代 码 是 


value = array; 
这 两 行 汇编 代码 是 指 取得 

















array 首 元 素 的 地 址 并 将 其 赋 给 


eax 和 寄存器， 然后 再 将 


eax 的 值 赋 给 


Value。 


工 ea 是 汇编 中 的 取 址 操作 。 








Ox0804841d <+48> : lea 
Ox08048420 <+51>: mov 
/* 
下 面 两 行 代码 对 应 的 

C 代 码 为 


Value = &array。 





其 仍然 是 取 


array 首 元 素 的 地 址 赋值 给 


Value。 


二 

Ox08048423 <+54>: lea 
Ox08048426 <+57>: mov 
/* 

这 两 行 代 码 对 应 


value=array[0]. 














注意 这 里 使 用 的 是 





mMmOV 汇 编 指 令 ， 即 将 值 赋 给 


eaX。 
*/ 
0x08048429 <+60>: mov 
0x0804842c <+63>: mov 
/* 
对 应 的 代码 为 


Value = &array[0]. 


-0x10 (Sebp) ,Seax 
Seax, -0x14 (%ebp) 


-0x10 (Sebp) ,Seax 
Seax, -0x14 (%ebp) 


-0x10 (Sebp) ,Seax 
Seax, -0x14 (%ebp) 


从 汇编 指令 中 可 以 明确 看 出 ， 





array. 


&array、 


&array[0]， 实 际 上 都 是 同一 个 地 址 。 


0x0804842f <+66>: lea -0x10 (Sebp) ,Seax 
0x08048432 <+69>: mov Seax, -0x14 (%ebp) 
/* 

对 应 的 代码 是 


value = pointer. 











注意 这 里 使 用 的 是 











ImOV 指 令 而 不 是 


ea 指令 。 是 将 指针 


int *pointer 的 值 


0 赋值 给 

Value。 
4 
0x08048435 <+72>: mov -0x18 (Sebp) ,Seax 
0x08048438 <+75>: mov Seax, -0x14 (%ebp) 
/* 


对 应 的 代码 是 


Value = &pointer.; 


int *pointer 的 地 址 赋值 给 


Value。 


/ 

0x0804843b <+78>: lea —0x18 (Sebp) ,Seax 
0x0804843e <+81>: mov Seax, -0x14 (Sebp) 
0x08048441 <+84>: mov $0x0, Seax 
0x08048446 <+89>: leave 

0x08048447 <+90>: ret 


End of assembler dump. 








通过 上 面 的 汇编 代码 ， 我 们 可 以 深入 地 理解 C 语 言 中 的 指针 和 数组 的 真正 含义 。 要 认识 到 指针 其 实 
就 是 一 个 变量 ， 只 不 过 这 个 变量 是 用 于 保存 地 址 的 《实际 上 也 可 以 保存 其 他 内 容 ， 如 一 个 整数 ) ,或 
者 说 它 保 存 的 值 可 以 被 视 为 地 址 。 因 为 指针 类 型 可 以 合法 地 使 用 “*”* 运 算 符 ， 做 提 领 运算 。 而 这 个 提 领 
运算 ， 其 实 就 是 将 变量 的 值 视 为 一 个 地 址 ， 然 后 从 这 个 地 址 中 读 取 值 。 














为 了 加 深 对 指针 本 质 的 理解 ， 请 看 下 面 的 例子 : 





#include <stdlib.h> 
#include <stdio.h> 
int main (void) 
{ 
Short *pl = 0; 
int **p2 = 0; 
EN 
二 二 亿 2 
printf("pl = %d, p2 = 8%qNn"，P1，P2) ， 
return 0; 








这 是 我 很 喜欢 的 一 道 题 目 。 大 家 可 以 想 一 下 ， 这 个 程序 是 否 会 裔 溃 ? 如 果 裔 泪 ， 原 因 是 什么 ? 如 
果 不 关 溃 ， 其 输出 结果 是 什么 ? 











如 果真 正 理解 了 指针 ， 看 完 代 码 ， 就 可 以 迅速 地 说 出 最 终 的 结果 。 如 果 你 还 在 犹 殉 ， 那 就 说 明 你 
对 指针 的 理解 还 不 够 透彻 。 


其 输出 结果 为 : 





[fgao@ubuntu chapter14]#./a.out 
pl = 2, p2= 4 





15.4 再 论 数组 首 地 址 


15.3 节 中 ， 





过 汇编 代码 ， 我 们 知道 array、&array 和 &array[0] 的 地 址 是 相同 的 ， 那 么 它们 三 者 是 否 
有 相同 的 含义 呢 ? 请 看 下 面 的 示例 代码 : 





#include <stdio.h> 
#include <stdlib.h> 
int main() { 

int a 














2] [3]; 
printf("&ald0 
Printf("&a[0 
printf ("size 
Printf ("Na") 
printf("&ald0 
printf("&a 
PETNtE (ss 
printf(™\Aa")s 
printf("a address is 
printf("a+1l address is Ox%X\n", a+1l); 
DEE 
printf 上 ("\n"); 
printf ("&a das is Ox%X\n", &a); 
printf("&a+l address 
eh anon i Bh 
printf ("\n") 
eturn 0 


] address is 0x%XxX\n", &al[0]); 
[0]+1 address is Ox%X\n", &al[0]+1); 
ize of pointer step is Ox%X\n", sizeof 


] [0] address is Ox%Xx\n", &al[l0] [0]); 
] [0]+1 address is 0xSsXNn"，&a[0] [0 
of pointer step is 0x%X\n", sizeof 


OxSX\n", a)s 


size of pointer step is Ox%X\n", sizeof 


is OxS$X\n", &a+l); 








size of pointer step is Ox%X\n", sizeof 


+1); 


*(&ga[ol [ol))); 


*(&a[o0]))); 


*a)); 





*(&a))); 








大 家 可 以 先 想 一 下 其 运行 结果 是 什么 ， 


然后 再 看 下 面 的 结果 : 





[fgao@ubuntu chapter1l5]#. 
&a[l0] [0] address is OxBF9 


/a.out 
03D48 


&a[0]0]+1 address is OxBF903D4C 
size of pointer step is Ox4 
&a[0] address is OxBF903D48 


&a[0]+1 address is OxBF90 


3D54 


Size of pointer step is OxC 


a address is OxBF903D48 
a+1 address is OxBF903D54 


size of pointer step is OxC 


&a address is OxBF903D48 
&a+1 address is OxBF903D6 








0 


size of pointer step is 0x18 








从 输出 上 看 ， 可 以 发 现 &a[0][0]、&a[0]、a， 


的 值 却 完 全 不 同 。 
为 什么 会 是 这 样 呢 ?因为 尽管 这 几 


-&a[0][0] 的 类 型 是 int*pointer， 所 以 步 长 为 4 字 节 


.&a[0] 的 类 





还 有 &a 的 地 址 值 都 是 相同 的 ， 











个 变量 的 地 址 相同 ， 但 是 


oO 


型 为 int (*pointer) [3]， 所 以 步 长 为 12 字 节 。 


:a 的 类 型 也 为 int(*pointer〉[3]， 所 以 其 步 长 也 为 12 字 节 。 


`&a 的 类 型 为 int(*pointer〉 [2][3]， 所 以 其 步 长 为 24 字 节 。 


然而 其 步 进 1 即 地 址 +1 


类 型 却 是 不 同 的 : 


15.5 “神奇 ”的 整数 类 型 转换 


整数 类 型 转换 经 常 被 当 作 笔试 题目 之 一 ， 大 家 可 能 会 觉得 那样 的 题目 很 简单 ， 也 许 同 样 会 觉得 本 
节 也 没什么 难度 。 请 大 家 先 耐心 看 一 下 下 面 的 示例 : 








#include <stdlib.h> 
#include <stdio.h> 
#define PRINT COMPARE RESULT(a, b) \ 
Ff (二 > by {~\ 
printf (#a. >. 下 #b "Ni 六 
} else if (a<b) I{\ 
printf(#a ™ < ™ #b NV N 
} else { \ 
printf(#a " =" #b "\n"); \ 
} 


int main (void) 


{ 


signed int a = -1; 
unsigned int pb = 2; 
signed short c = -1; 


unsigned short d = 2; 

PRINT COMPARE RESULT (a, b); 
PRINT COMPARE RESULT (c, d); 
return 0; 














大 多 数 同学 可 能 都 遇 到 过 这 类 将 a 和 b 进 行 比较 的 题目 ， 结 果 是 a>b， 原 因 也 很 简单 明确 : 当 signed 
int 和 unsigned int 进 行 比 较 时 ，signed int 会 被 转换 为 unsigned int。-1 的 值 即 0xFFFFFFFF， 就 被 视 为 无 符号 
整数 的 最 大 值 ， 因 此 a>b。 然 而 对 于 c 和 d 来 说 ， 其 类 型 分 别 是 signed short 和 unsigned short， 那 么 结果 又 
会 是 什么 呢 ? 请 看 下 面 的 输出 ; 








[fgao@ubuntu chapter15]#./a.out 
a>pb 
c<d 





~ 








是 不 是 感觉 有 些 意外 ? 为 什么 仅仅 从 int 变 为 short， 其 结果 就 截然 不 同 了 呢 ? 





原因 在 于 C 标 准 规定 ， 当 进行 整数 提升 时 ， 如 果 int 尖 型 可 以 表示 原始 类 型 的 所 有 值 时 ， 它 就 被 转换 
为 int 类 型 ， 不 然则 被 转换 为 unsigned int。 所 以 当 c 和 d 进 行 比较 时 ，c 和 d 的 类 型 分 别 是 short 和 unsigned 
short， 那 么 它们 就 会 被 转换 为 int 类 型 ， 则 实际 是 对 (int) -1 和 (int) 2 进行 比较 ， 结 果 自 然 是 c<d。 


15.6 ”小心 volatile 的 原子 性 误解 





关于 volatile 的 说 明 ， 是 一 个 老生 常 谈 的 问题 。 其 定义 很 简单 ， 可 以 理解 为 易 变 的 ， 防 止 编 译 器 对 
其 优化 。 因 此 其 用 途 一 般 有 以 下 三 种 : 


:外 部 设备 寄存 器 映射 后 的 内 存 一 一 因为 外 部 寄存 器 随时 可 能 由 于 外 部 设备 的 状态 变化 而 改变 ， 
此 映射 后 的 内 存 需 要 用 volatile 来 修饰 。 


` 多 线程 或 异步 访问 的 全 局 变量 。 


岁入 式 编程 一 一 防止 编译 器 对 其 优化 。 





对 第 1 种 和 第 3 种 的 用 途 大 家 基本 上 都 不 会 有 什么 误解 ， 但 经 常会 错误 地 理解 第 2 种 情况 : 认为 int 类 
型 的 加 减 操作 是 原子 的 ， 因 此 在 使 用 了 volatile 后 ， 就 无 须 使 用 锁 来 进行 竞争 保护 了 。 比 如 下 面 这 样 的 
代码 : 





static Volatile int counter = 0; 
void adqd counter (void) 


++Counters 





其 反 汇编 代码 为 : 





adqd counter: 

pushl sebp 

movl %esp, %Sebp 
movl counter, %Seax 
addl $1, Seax 

movl %eax, counter 
popl sepbp 

Et 





上 面 的 汇编 代码 ， 首 先是 将 counter 的 值 保存 到 eax 寄 存 器 ， 然 后 对 eax 进 行 加 1 操作 ， 最 后 再 将 eax 的 
值 保 存 到 counter 中 。 这 样 ，++counter 就 绝 不 可 能 是 原子 操作 了 ， 必 须 使 用 锁 保 护 。 








那么 volatile 对 于 变量 来 说 ， 完 竟 有 什么 样 的 效果 呢 ? 下 面 的 代码 对 上 面 的 代码 进行 了 一 些 修 改 : 





static int counter = 0; 
void adqd counter (void) 


for (; counter != 10;) 1 
++Ccounter; 





用 gcc-S-O 15 6_volatile.c 生 成 对 应 的 汇编 代码 : 





adqd counter: 
.LFBO: 
:Ofi Startproc 


movil counter, %Seax 
cmpl $10, Seax 


Je sBL 
.14: 
adqdl $1, Seax 
cmpl $10, %eax 
jne L4 
movil $10, counter 
Ti 
rep ret 
.Cfi endproc 
.LFEO: 








从 上 面 的 汇编 代码 可 以 清晰 地 看 出 ， 在 进入 add counter 后 ， 首 先 会 将 counter 的 值 赋 给 eax 寄 存 器 ， 
然后 eax 进 行 加 1 操作 ， 再 与 立即 数 10 进 行 比 较 。 也 就 是 说 ，for 循 环 的 C 代 码 只 涉及 eax 寄 存 器 ， 而 不 会 
对 counter 进 行 任 何 访问 。 














接 下 来 ， 对 counter 添 加 上 volatile 修 饰 符 : 


static Volatile int counter = 0; 
void add counter (void) 
{ 
for (; counter != 10; ) { 
++counter; 


} 


然后 生成 汇编 代码 gcc-S-O 15_6_volatile2.c: 





adqd counter: 


EPBOS 
“Gf1i Startproc 
movl counter, %eax 
cmpl $10, %eax 
je :Ll 

:3 
movil Counter, %Seax 
adqdl $1, Seax 
movil Seax, Counter 
movil counter, %Seax 
cmpl $10, %eax 
jne sb3 

ali 
rep ret 


.Cfi endproc 


























与 没有 volatile 的 汇编 代码 相 比 ， 其 差异 很 明显 。 使 用 了 volatile 之 后 ， 与 counter 的 自 增 操作 对 应 的 
汇编 代码 ， 每 次 都 要 重新 从 counter 读 取 值 ， 再 将 其 赋值 给 eax 寄 存 器 。 























现在 对 volatile 的 理解 就 比较 深刻 了 。volatile 只 能 保证 在 访问 该 变量 时 ， 每 次 都 是 从 内 存 中 读 取 最 
新 值 ， 并 不 会 使 用 寄存 器 中 缓存 的 值 。 而 对 该 变量 的 修改 ，volatile 并 不 提供 原子 性 的 保证 








O 


15.7 ”有 趣 的 问题 : “= 一 x" 何 时 为 假 ? 





看 到 这 个 题目 ， 大 家 可 能 会 想到 一 些 比较 另类 的 方法 ， 比 如 使 用 宏 定 义 ， 或 者 用 高 级 语言 中 的 操 
作 符 重 载 之 类 的 。 但 如 果 说 要 求 使 用 最 原始 的 C 语 言 表 达 式 ， 那 么 什么 时 候 “x==x” 会 是 假 呢 ? 请 看 下 面 
的 代码 : 





#include <stdlib.h> 
#include <stdio.h> 
#include <string.h> 
int main (void) 
{ 

下 二 aE. 这 去 人 0 芭 下 下 在 在 在 在 下 站 











if (x == x) { 
printf ("Equal\n"); 
} 
else { 
printf ("Not equal\n"); 
} 
if (x >= 0) { 
printf ("x(%f) >= 0\n", x); 
} 
else if (x < 0) { 
Drintf (vx (TE) < ON x 


} 

int a = Oxffffffff; 
memcpy (&x, &a, sizeof (x)); 
if (x == x) { 





printf ("Equal\n"); 
} 
else { 
printf ("Not equal\n"); 


if (x >= 0) 1{ 
printf ("x(%f) >= 0\n", x); 
} 


else if (x < 0) { 








printf ("mx (TE), :< ONm KR) 
} 
else 1{ 
printf ("Surprise x(%f)!!!\n", x); 
} 
return 0; 





gcc-Wall 15_7_float.c 编 译 并 执行 。 输 出 结果 如 下 所 示 : 





[fgao@ubuntu chapter1l5]#./a.out 
Equal 

x(4294967296.000000) >= 0 

Not equal 

Surprise x(-nan)!!! 





这 样 的 结果 是 不 是 有 些 意 外 呢 ? 





简单 解释 一 下 其 中 的 原因 : 


` 当 float x=0xffff 时 ， 将 整数 赋值 给 一 个 浮 点 数 ， 由 于 float 和 lint 都 占用 了 4 字 节 ， 但 浮 点 数 的 存储 
格式 与 整数 不 同 ， 其 需要 一 定 的 数位 来 作为 小 数位 ， 所 以 float 的 表示 范围 要 小 于 int。 这 里 涉及 了 C 语 言 
中 的 类 型 转换 。 














` 当 整数 转换 为 浮 点 数 时 ， 尽 管 数值 会 有 所 变化 ， 但 结果 一 定 是 一 个 合法 的 浮 点 值 。 所 以 x 一 定 等 于 
x， 且 x 不 是 大 于 等 于 0， 就 是 小 于 0。 





: 当 使 用 memcpy 将 0xff 填 充 到 x 的 地 址 时 ， 这 时 保证 了 x 储 存 的 一 定 是 0xffffffff， 但 很 可 惜 它 不 是 一 个 





合法 的 浮 点 值 ， 而 是 一 个 特殊 值 NaN。 


作为 一 个 非法 的 浮 点 数 NaN， 当 它 与 任何 数值 相 比 较 时 ， 都 会 返回 








果 x==x 为 假 ，x 即 不 大 于 0， 不 小 于 0， 也 不 等 于 0。 





假 。 所 以 就 有 了 比较 意外 的 结 


1$.8 小心 浮 点 陷阱 


15.7 节 通过 “x==x” 为 假 这 个 问题 ， 引 出 了 一 个 特殊 的 浮 点 值 NaN。 枉 将 挖 抉 出 更 多 的 浮 点 陷阱 。 





1$.8.1 浮 点 数 的 精度 限制 


浮 点 数 的 存储 格式 与 整数 完全 不 同 。 大 部 分 的 实现 采用 的 是 IEEE 754 标 准 ，float 类 型 是 1 个 sign 
bit、8 个 exponent bits 和 23 个 mantissa bits 。 而 double 类 型 是 1 个 sign bit、11 个 exponent bits 和 52 个 mantissa 
bits。 关 于 浮 点 数 是 如 何 表示 小 数 部 分 的 ， 大 家 可 以 自行 参考 维基 百科 。 简 单 来 说 ， 小 数 部 分 是 依靠 2 
的 负 多 少 次 方 来 近似 表示 的 ， 因 此 浮 点 数 存在 精度 的 问题 ， 对 浮 点 数 进 行 比较 时 ， 要 使 用 范围 比较 。 














#include <stdlib.h> 
#include <stdio.h> 
int main (void) 
{ 
float x = 0.123-0.11-0.013; 
if (x == 0) { 
printf.("x Fs. OTNA) 


if (-0.0000000001 <x && x < 0.0000000001) { 
printf("x is in 0 range!\n"); 
} 


return 0; 


编译 输出 : 


[fgao@ubuntu chapterl5]#gcc -Wall 15 8 floatl.c 
[fgao@ubuntu chapter1l5]#./a.out 
x is in 0 range! 


从 数学 的 角度 看 ，float x=0.123-0.11-0.013， 得 到 的 一 定 是 0。 但 对 于 浮 点 数 来 说 ， 因 为 其 不 能 精确 
地 表示 小 数 ， 因 此 x 最 终 的 结果 是 一 个 趋 近 于 0 的 值 。 故 而 不 能 用 0 和 x 直接 进行 比较 ， 而 是 要 使 用 一 个 
范围 来 确定 x 是 否 为 0。 




















15.8.2 ”两 个 特殊 的 浮 点 值 


浮 点 数 有 两 个 特殊 的 值 ， 除 了 前 面 的 NaN (Nota Number) ， 还 有 一 个 infinite 即 无 限 。15.7 节 中 ， 
使 用 memcpy 构 造 了 一 个 NaN 的 浮 点 数 。 可 能 有 人 会 问 ， 平 常 有 谁 会 用 memcpy 去 填充 浮 点 数 呢 ? 因此 我 
不 可 能 遇 到 NaN。 那 么 ， 请 看 下 面 的 示例 ; 














#include <stdlib.h> 
#include <stdio.h> 
int main (void) 


float x = 1/0.0; 
printf("x is Sf\n"; x)} 
x= 0/0.0; 

亿 芝 请 


return 0; 





其 输出 结果 为 : 





[fgao@ubuntu chapter1l5]#./a.out 
x is inf 
x is -nan 





当 1 除 以 0.0 时 ， 得 到 的 是 infinite， 而 用 0 除 以 0.0 时 ， 得 到 的 就 是 NaN。 虽 然 这 里 完全 只 是 一 则 普通 
的 除法 运算 ， 但 也 会 产生 NaN 的 情况 。 





那么 当 使 用 除法 运算 时 ， 对 除数 进行 检查 ， 保 证 其 不 为 0.0， 是 否 就 可 以 避免 NaN 了 ? 再 看 下 面 的 
代码 : 





#include <stdlib.h> 
#include <stdio.h> 
int main (voidgd) 
{ 
float x; 
while (1) { 
scanf ("%f", &x); 
printf ("x 8 SE\N"T, RK)» 


return 0; 





编译 执行 : 





[fgao@ubuntu chapter15]#gcc -Wall 15 8 float3.c 
[fgao@ubuntu chapter15]#./a.out 

inf 

芒 生 仿 . 主 认 下 

nan 

x is nan 





上 面 的 代码 中 使 用 了 scanf 来 得 到 用 户 输入 的 浮 点 数 。 令 人 惊讶 的 是 ，scanf 不 仅 接 受 inffinan 的 输 
入 ， 并 将 其 视 为 浮 点 数 的 两 种 特殊 值 。 那 么 对 于 UI 程序 来 说 ， 当 过 到 浮 点 数值 的 时 候 ， 我 们 必须 首先 
判断 其 是 否 为 合法 的 浮 点 值 。 笔 者 就 遇 到 过 一 个 开源 库 返 回 的 浮 点 数 为 NaN 的 情况 。 令 人 高 兴 的 是 ，C 





























库 提 供 了 两 个 库 函 数 isinf 和 isnan， 分 别 用 于 判断 浮 点 数 是 否 为 infinite 和 NaN。 


15.9 ”Intel 移 位 指令 陷阱 


假设 操作 平台 为 32 位 平台 ， 请 看 下 面 的 示例 代码 : 








#include <stdio.h> 
int main() 





{ 

#define MOVE CONSTANT BITS 32 
unsigned int move step=MOVE CONSTANT BITS; 
unsigned int valuel = 1lul << MOVE CONSTANT BITS; 
printf ("valuel is 0x%X\n", valuel); 
unsigned int value2 = lul << move step; 
printf ("value2 is 0x%X\n", value2); 
return 0; 














上 面 的 代码 中 ，valuel 使 用 立即 数 32 进 行 左 移 ， 而 value2 使 用 一 个 变量 move_step 进 行 左 移 ， 且 
move_step 的 值 也 是 32。 那 么 问题 来 了 ， 最 后 value1 和 value2 的 值 是 什么 ? 我 相信 大 部 分 人 都 会 说 最 后 两 
个 值 是 一 样 的 ， 都 是 0。 那 么 ， 请 看 出 人 意料 的 实际 结果 : 











[fgao@ubuntu chapter15]#./a.otUt 
valuel is 0x0 
value2 is Oxl 





为 了 解释 这 个 意外 的 结果 ， 我 们 再 次 祭 出 反 汇 编 这 一 利器 : 





Dump of assembler code for function main: 











0x0804841Q <+0>: push Sebp 

0x0804841e <+1>: ImOV Sesp, sebp 
0x08048420 <+3>: and $Oxfffffff0,$Sesp 
0x08048423 <+6>: sub $0x20, Sesp 
0x08048426 <+9>: movl $0x20, 0x14 (Sesp) 
0x0804842e <+17>: movil $0x0, 0x18 (Sesp) 
0x08048436 <+25>: mov 0X18 (Sesp), Seax 
0x0804843a <+29>: mov Seax, 0x4 (Sesp) 
0x0804843e <+33>: movil $0x8048510, (Sesp) 
0x08048445 <+40>: call 0x80482f0 <printf@plt> 
0x0804844a <+45>: mov 0X14 (Sesp), Seax 
0x0804844e <+49>: mov $0xl1, Sedx 
0x08048453 <+54>: mov Seax, SECcx 
Ox08048455 <+56>: shl SCl1, Sedx 
0x08048457 <+58>: mov Sedx, Seax 
Ox08048459 <+60>: mov Seax, Oxlc (Sesp) 
0x0804845d <+64>: mov 0X1C (Sesp) ,Seax 
0x08048461 <+68>: mov Seax, 0x4 (Sesp) 
0x08048465 <+72>: movil $0x8048520, (Sesp) 
Ox0804846c <+79>: call 0x80482f0 <printf@plt> 
0x08048471 <+84>: mov $0x0, Seax 
0x08048476 <+89>: leave 

0x08048477 <+90>: ret 














End of assembler dump. 





第 6 行 汇编 代码 mov1$0x0，0x18 〈%esp) 对 应 的 C 代 码 为 unsigned int 
valuel=lul<<MOVE_ CONSTANT BITS。 也 就 是 说 ， 对 于 变量 value1， 编 译 器 直接 生成 了 结果 0 一 一 该 结 
果 也 是 我 们 预期 的 结果 。 而 对 于 value2， 则 是 真正 使 用 了 左 移 移 位 指令 shl。 那 么 问题 就 转变 成 了 为 什么 
对 一 个 int 整 数 左 移 32 位 ， 其 结果 不 是 0 呢 ? 


请 看 Intel 的 指令 手册 中 关于 shl 的 说 明 : 


SAL/SAR/SHL/SHR— hift (Continued) 一 一 32 位 机 


Description 


These instructions shift the bits in the first operand (destination operand) to the left or Tight by the number 
of bits specified in the second operand (count operand) .Bits shifted beyond the destination operand boundary 
are first shifted into the CF flag, then discarded.At the end of the shift operation, the CF flag contains the last 


bit shifted out of the destination operand. 


The destination operand can be a register or a memory location.The count operand can be an immediate 
value or register CL.The count is masked to five bits, which limits the count range to 0 to 31.A special opcode 


encoding is provided for a count of 1. 





现在 真相 大 白 了 。 原 来 在 32 位 机 器 上 ， 保 存 移 位 个 数 的 指令 位 只 有 5 位 。 那 么 当 执 行 左 移 32 位 时 ， 
实际 上 就 是 左 移 0 位 ， 即 没有 任何 变化 。 所 以 value2 左 移 32 位 时 ， 其 值 仍然 为 1。 














在 32 位 机 器 上 ， 实 际 左 移 位 数 等 于 “指定 位 数 &0x1F”。 





说 明 “在 64 位 机 器 上 ， 要 将 Value 1 和 Value 2 修改 为 long 类 型 左 移 64 位 进行 测试 。 





